20.08.2024, 17:17 | #1 |
Участник
|
Как гарантированно проверить что объект = null
Привет.
При проверке на null бывают интересные случаи. Например, добавили контрол на форме X++: formStringControl = element.design().addControl(FormControlType::String, "TestControl"); X++: element.design().removeControl(formStringControl.id()); Если же в коде проверять X++: if (formStringControl) Но попытка вызвать на ней любой метод приводит к исключению. Как можно предупредить такие случаи и понять что объект за ссылкой уже убит и она невалидна ? Ведь отладчик как-то это понимает при отображении значения в окне просмотра значений переменных. Есть обходной способ - не хранить ссылки на контролы, а запоминать их идентификаторы и по мере надобности каждый раз доставать контрол по идентификатору. X++: formStringControl = element.design().addControl(FormControlType::String, "TestControl"); id = formStringControl.id(); ... element.design().removeControl(id); ... if (id) { formStringControl = element.design().control(id); if (formStringControl) // безопасная проверка - точно можно понять контрол еще жив или нет ... } |
|
20.08.2024, 18:15 | #2 |
Участник
|
В методе SysClassWizard.frameworkInitGroups() в связке с удалением объекту контрола сразу же присваивается значение null.
Думаю - так и надо сразу делать. X++: this.design().removeControl(formGroupControl.id());
formGroupControl = null;
__________________
// no comments |
|
|
За это сообщение автора поблагодарили: Logger (3). |
20.08.2024, 18:49 | #3 |
Участник
|
Цитата:
Для описанного случая подходит. Но вопрос немного шире. Как проверить валидность ссылки в целом. Бывают и другие ситуации. |
|
21.08.2024, 07:24 | #4 |
Участник
|
По сути, вы сами всё расписали. Надо заново найти контрол по id.
X++: formStringControl = element.design().control(id); if (formStringControl) // безопасная проверка - точно можно понять контрол еще жив или нет Попробуем углубиться в детали. У вас переменная ссылается на объект, контрол, который пока что существует. Метод removeControl() находит объект по id и удаляет его из памяти. Будет ли метод обновлять все ссылки на удаленный объект? Думаю нет. Соответственно, у вас останется ссылка на некую область в памяти, обращение к которой даст сбой. Однако проверка на неравенство null завершится успешно. Плюс, я думаю, что дебаггер немного доработан с тем, чтобы не показывать тот фарш, который может отобразить переменная, если она ссылается не туда, куда надо.
__________________
// no comments |
|
22.08.2024, 06:16 | #5 |
Участник
|
|
|
22.08.2024, 10:02 | #6 |
Участник
|
то же самое
Также не работает X++: classIdGet typeOf(formStringControl ) == 44 ClrInterop::isNull |
|
23.08.2024, 00:16 | #7 |
Участник
|
Привет.
За все возможные object'ы не скажу, но что касается formControl'ов здесь можно использовать hWnd. Соответственно решением данной проблемы будет проверка его на действительность. isWindow у WinApi, легко выявляет данную проблему: X++: FormControl c; int hWnd; ; c = element.design().addControl(FormControlType::Button, 'tst'); hwnd = c.hWnd(); info(int2str(WinApi::isWindow(hwnd))); // 1 element.design().removeControl(c.id()); info(int2str(WinApi::isWindow(hwnd))); // 0 Шанс, как обычно, стремится к 0 у единичного юзера и возрастает с увеличением их количества. Стоит ли подстраховываться?...Зависит от того какую задачу решаете. Последний раз редактировалось Товарищ ♂uatr; 23.08.2024 в 00:40. |
|
|
За это сообщение автора поблагодарили: Logger (5). |