Igor_G писал(а):Извините, но позвольте с Вами не согласится. Читаем внимательно отсканированную стр. 14.
Интересно, с чем именно вы не согласились?
Я всё корректно написал. Ещё раз:
dadreamer писал(а):Смотря какой. HWND - это только окошки.
То, что в Windows хэндлы повсеместно используются, совсем не секрет для сколь-нибудь продвинутого юзера. И это никто не отрицал ни разу. А вот тип хэндла HWND управляет только окнами. Цитата
отсюда:
Window Handles
Windows are objects — they have both code and data — but they are not C++ classes. Instead, a program references a window by using a value called a handle. A handle is an opaque type. Essentially, it is just a number that the operating system uses to identify an object. You can picture Windows as having a big table of all the windows that have been created. It uses this table to look up windows by their handles. (Whether that's exactly how it works internally is not important.) The data type for window handles is HWND, which is usually pronounced "aitch-wind." Window handles are returned by the functions that create windows: CreateWindow and CreateWindowEx.
Цитата
отсюда:
So, a HWND is a HANDLE, but not all HANDLEs are HWND. In fact:
typedef void *PVOID;
typedef PVOID HANDLE;
typedef HANDLE HWND;
A "handle" is the general term used to refer to a token that identifies a resource on the system (a menu, a DLL module, a block of memory, etc). Often referred to as a "magic cookie", it's normally returned when you first create the resource. You then pass that handle to other functions in the API responsible for processing the resource. You normally need not know what the handle is however. Sometimes it may be a pointer, other times a number, perhaps a structure, or whatever. That's why they hide it using names like HWND which is simply the handle used to identify a window (returned by the API function "CreateWindow()").
И таких цитат можно тысячу набрать, при желании, ибо это прописные истины.
Кстати, на этих страницах книги ни слова о хэндлах вида magic cookie. Между прочим, такие хэндлы не обязательно должны быть сопоставлены с каким-либо объектом в памяти (могут и не быть).
Igor_G писал(а):Kросс-платформенность обеспечивается потому-что Чарльз Симонаи был далеко не глупым человеком - (см. отсканированную стр. 4).
Какое отношение имеет этот Чарльз Симонаи к кросс-платформенности
?
Цитата из вашей же книжки:
В любой книге, посвященной программированию под Windows, вы найдете упоминание о том, что один из первых разработчиков Windows Чарльз Симонаи, венгр по происхождению, начал использовать в своих программах способ именования переменных, который впоследствии назвали венгерской системой.
Ну, и как это понимать?
Погуглите, что такое кросс-платформенность. И что нужно сделать при написании программы (особенно такой как
), чтобы её добиться.
КАК ОПРЕДЕЛИТь ХЭНДЕЛ ЭЛЕМЕНТА НА FP?
То что это возможно - это факт. Это мне ответил NI Support и дал линк
на эту страницу. Это-же я читал где то в LAVA (к сожалению найти сегодня линк больше не могу).
Повторяю - у объектов на FP хэндлов нет! Не верите мне и
Vitekkz88 - вот слова
Rolf Kalbermatter, съевшего собаку на этих вещах (
1,
2):
As Chaos said, you simply can't do that. All the front panel objects in LabVIEW are actually LabVIEW objects and absolutely NOT based on Windows standard controls. So there is no Windows HWND associated with them at all.
You can't get a HWND from a LabVIEW control. They are not implemented as Windows child window but are instead entirely handled by LabVIEW internally. The only thing in LabVIEW that has an associated Windows handle are the panels itself.
Если и этого мало - возьмите WinSpy или встроенный в LV Window Monitor и смотрите, какие хэндлы возвращаются.
А NI просто вам кинули ссыль на врапперы (причём, уже устаревшие) на некоторые функции WinAPI - типа, "сами там возитесь с вашими нам непонятными задачами"
Igor_G писал(а):Не уже ли ни у кого нет идей? Не ужели это на самом деле ни кто не пробовал?
А зачем кому-то это вообще может понадобиться? Между прочим, вам уже была дана подсказка:
dadreamer писал(а):а всё-таки, выполнять работу с GUI во времякритичных подпрограммах - не есть хорошо.
Однако вы её не увидели. Или не захотели. Опять пытаетесь войти в дом, не как все люди, а через чердак. Сколько у вас подобных тем уже было?.. То компилятор
оптимизировать собирались, то переделать существующие
для работы с файлами... Сплошь фантастика!
В вашем случае достаточно было бы вынести работу с гуями в отдельный поток и синхронизироваться через очереди/уведомители. Примеров на форуме полно. Другим, пожалуй более экзотическим решением, было бы написать весь GUI в другой среде и оформить в виде библиотеки. Тогда бы вы получили независимость потока обработки от UI потока (DLL реентерентная, естественно). Ну, хотите, продолжайте микроскопом гвозди забивать - ваше дело.