|
|
UbuntuGTK2.png (53,575 bytes) Win64InDll.png (42,294 bytes) Win64inTheHost.png (34,079 bytes) |
|
|
Remark: The issue appears only when the form in host application and the form in dll both contains the same controls (Combobxes or listbox) - the same problem. In the given example if combobox from host app removed it is ok. If the host application is not lazarus application, there is no any problems. |
|
|
More info: If I set Host app combobox property "Visible" to false in design time, it starts to work in dll form. But if a set progmaticaly to false just before open the form in dll, it does not affect and the problem persists. I think it is related some-how with windows messages loop when both host and dll are written in Lazarus. |
|
|
Update: issue also with "OnExit" combobox event in dll form. it wil not fire this event if parent host app form contains combobox control. please find new example attached, just try to leave the combobox field in dll form with mouse or "tab" key and you will not see ShowMessage dialog control because it will not fire OnExit event. Please find attached new sample and small video that demonstrates the problem. r9oJCHREeg.mp4 (943,993 bytes) |
|
|
I found a reason and fix it. The problem: The problem comes again from the Windows (the "great" OS). All those three type of controls: TComboBox; TListBox and TChecklistBox (which causes a problems) using a FinishCreateWindow procedure in Win32WSControls.pp unit, line 177. The problem comes from line 0000198: if not GetClassInfoW(System.HInstance, PWideChar(WideString(pSubClassName)), @DummyClassW) then ..... And how it happens: if in the parent application you have in your active screen form some of TComboBox; TListBox or TChecklistBox, the call of GetClassInfoW at line 198 will return FALSE and it will register a sub-class with a name of 'LCLComboBox', 'LCLListBox' or 'LCLCheckListBox' with Windows.RegisterClassW(@WindowClassW); at line 206 . then, When you call a form into LCL DLL unit that have the same (TComboBox; TListBox or TChecklistBox) components over it, it will again call FinishCreateWindow, but in that moment Although hinstanse parameter is different that the HInstanca of the caller application, stupid Windows returns, that the subclass with the same name is allready registered. But unfortunately, this is not a right sublass, ,this is the subclass of the parent (host) LCL application. In that case, this will not register a SubClassWndProc, which explains why all the messages(WM_REPAINT, WM_KILLFOCUS and so on) was not handled from the controls in a dll. The fix: I defined a three new subclass names in Win32Int.pp: LCLComboboxClsNameDLL: array[0..14] of char = 'LCLComboBoxDLL'#0; LCLListboxClsNameDLL: array[0..13] of char = 'LCLListBoxDLL'#0; LCLCheckListboxClsNameDLL: array[0..18] of char = 'LCLCheckListBoxDLL'#0; I did a small check inside Win32WSStdCtrls and Win32WSCheckLst: in class function TWin32WSCustomComboBox.CreateHandle(const AWinControl: TWinControl; replaced pSubClassName := LCLComboboxClsName with if IsLibrary then pSubClassName := LCLComboboxClsNameDLL else pSubClassName := LCLComboboxClsName; inside class function TWin32WSCustomListBox.CreateHandle(const AWinControl: TWinControl; replaced pSubClassName := LCLListboxClsName with if IsLibrary then pSubClassName := LCLListboxClsNameDLL else pSubClassName := LCLListboxClsName; and finally in class function TWin32WSCustomCheckListBox.CreateHandle( const AWinControl: TWinControl; const AParams: TCreateParams): TLCLIntfHandle replaced pSubClassName := LCLCheckListboxClsName with if IsLibrary then pSubClassName := LCLCheckListboxClsNameDLL else pSubClassName := LCLCheckListboxClsName; Now, everything seems to be OK. win32wsstdctrls.diff (864 bytes) win32wschecklst.diff (574 bytes) win32int.diff (824 bytes) |
|
|
Is not the better way to check if window class not registered, then register it? |
|
|
It is this check that gives the wrong result. Windows returns that the class is registered when the function is called in DLL, although it is not registered in it. It is registered in the host app. But Windows threat host and dll as a same app instance, although they have dihherent hinstance. The way to avoid this is to change sub class name in DLL. In that case it works fine. |
|
|
> Windows returns that the class is registered when the function is called in DLL, although it is not registered in it. I made a simple project. In Windows 7 x64, this all works as it should, i.e. the dll reports that the class is not registered, even if it is registered in the host application. uSimpleClassReg.pp (870 bytes) project1Dll.lpr (429 bytes) project1Exe.lpr (1,039 bytes) |
|
|
You are right for the case ypu developed, but it is not a same case that I report as a bug. You made a console application (you miss all LCL initialization lifecycle in host application). Your dll library miss dependency from the LCL and initialization of application object inside DLL library. I modify your project and after add the missing dependencies, change host app from console to standard windows application, add a ne method in DLL that initialize application object inside DLL. And the bug appear again (Windows 10 x64, Windows 7 X64). Here you are. Parallels Picture.png (9,938 bytes) |
|
|
I change Unit1 so that it can be compiled in FPC 3.2.0 as well. Lazarus 2.0.10 or Lazarus 2.1.0 revision 63735 - result is OK, i.e. like console App. Windows 7, x64. unit1.pp (1,771 bytes) Screen.jpg (29,907 bytes) |
|
|
My friend, Your test is right, but again is different than the issue I reported. I talking for a PLUGIN library, which is loaded dynamically with SafeLoadLibrary. Plugin library can not be linked like you propose - plugin must be load/unload dynamically. Please, do your test on this way (put my code over your button click handler): Type TDllFunc = function : Boolean; stdcall; procedure TForm1.Button1Click(Sender: TObject); Var DllIsRegistered : TDllFunc; DllRegister : TDllFunc; DllUnRegister : TDllFunc; DllInit : TDllFunc; LIbHandle : TLibHandle; begin LIbHandle := SafeLoadLibrary( 'project1Dll.dll' ); if LIbHandle<>0 then begin DllIsRegistered := TDllFunc( GetProcAddress( LIbHandle, 'DllIsRegistered')); DllRegister := TDllFunc(GetProcAddress( LIbHandle, 'DllRegister')); DllUnRegister := TDllFunc(GetProcAddress( LIbHandle, 'DllUnRegister')); DllInit := TDllFunc(GetProcAddress( LIbHandle, 'DllInit')); if Assigned(DllInit) and Assigned(DllIsRegistered) and Assigned(DllRegister) and Assigned(DllUnRegister) then begin Memo1.Lines.Clear; Memo1.Lines.Add('Dll Init = '+ ifthen(Boolean(DllInit), 'True','False')); Memo1.Lines.Add('Is registered in EXE = '+ ifthen(IsClassRegistered(HInstance), 'True','False')); Memo1.Lines.Add('Regiser in EXE result = '+ ifthen(RegisterClass(HInstance), 'True','False')); Memo1.Lines.Add('Is registered in EXE = '+ ifthen(IsClassRegistered(HInstance), 'True','False')); Memo1.Lines.Add('Is registered in DLL = '+ ifthen(Boolean(DllIsRegistered), 'True','False')); Memo1.Lines.Add('Regiser in DLL result = '+ ifthen(Boolean(DllRegister), 'True','False')); Memo1.Lines.Add('Is registered in DLL = '+ ifthen(Boolean(DllIsRegistered), 'True','False')); Memo1.Lines.Add('UnRegiser in DLL result = '+ ifthen(Boolean(DllUnRegister), 'True','False')); Memo1.Lines.Add('Is registered in DLL = '+ ifthen(Boolean(DllIsRegistered), 'True','False')); Memo1.Lines.Add('Is registered in EXE = '+ ifthen(IsClassRegistered(HInstance), 'True','False')); Memo1.Lines.Add('UnRegiser in EXE result = '+ ifthen(UnRegisterClass(HInstance), 'True','False')); Memo1.Lines.Add('Is registered in EXE = '+ ifthen(IsClassRegistered(HInstance), 'True','False')); end else ShowMessage('Get Proc Address failed!'); end else begin ShowMessage('Unable to load library!'); end; end; |
|
|
And the new files in samle host project umain.lfm (623 bytes) umain.pas (4,038 bytes) |
|
|
Equally. unit1-2.pp (3,033 bytes) Screen-2.jpg (31,533 bytes) |
|
|
There is something wrong. In the way you call the function WriteStr(S, 'Is registered in DLL = ', DllIsRegistered); It will NOT call the function in DLL. You can try to put a breakpoint in DLL in function DllIsRegistered and the breakpoint is never reached. So, please, use the following code, which causes to call a function in DLL B := Boolean( DllIsRegistered ); WriteStr(S, 'Is registered in DLL = ', B ); OR WriteStr(S, 'Is registered in DLL = ', Boolean( DllIsRegistered ) ); In that case the breakoint in DLL is reached. and the result is TRUE. I am sorry my friend but I am right - there is a problem in LCL with registerclass id DLL. |
|
|
I tried with changing the way you write: [code] B := DllIsRegistered(); WriteStr(S, 'Is registered in DLL = ', B); Dest.Append(S); [/code] and so on. Result not changed - first "Is registered in DLL" = FALSE And, by the way, the code could not fail to reach the DLL, this is shown by the results of the function. What version of Windows do you have? |
|
|
7, 10 64 bit - result is the same. In your way to function call there is not problem. In my way - there is. You are using B := DllIsRegistered(); I am using B := Boolean( DllIsRegistered ); In both cases reach break point in dll in your case result is False in my case - it is true. Any ideas? |
|
|
Please try to examine the Hinstance of the returned WNDClass if it finds a class already created.. if the Hinstance isn't the same as the DLL HInstance then alter the code to force it to make an attempt to create another class but it will have now the DLL Hinstance. EDIT: Looking at MS Docs, it states that all classes registered in a DLL must be unregistered from the DLL before it exits. The OS will not automatically unregister any classes registered in a DLL, the user code must do it. As for the host app, the OS will unregister those within the host without the call to the API. So keep this in mind. |
|
|
I examined it, the result is that HInstance=dll hinstance. I try then following: ( in FinishCreateWindow, Win32WSControls.pp) ...... B := GetClassInfoW(System.HInstance, PWideChar( WideString(pSubClassName) ), @DummyClassW) ; // return TRUE, DummyClassW.hInstance=dll hInstance. if B then B:=Windows.UnregisterClassW(PWideChar( WideString(pSubClassName) ), System.HInstance); // Here return false, and the error code=1412. Err := Windows.GetLastError; // return 1412 B := GetClassInfoW(System.HInstance, PWideChar( WideString(pSubClassName) ), @DummyClassW) ; // still retunr TRUE, the class registerredm but it is not registerred in the DLL if not B then begin with WindowClassW do ..... And I received err 1412 = 1412 (0x584) Class still has open windows. The only open window in that moment is parent window in the host application. Any ideas??? |
|
|
I keep insisting that the solution to the problem is to change the class name in Dll. |
|
|
I'm not sure why. As you can see, in my case, registration in the DLL and EXE are independent. Although the combobox example shows the same bug. |
|
|
if checking for the Class returns a class already created with the DLL instance handle then I would say its has already been registered and you are doing something wrong. You should not get a return back indicating that it's already registered with the current DLL instance handle, that can only happen somewhere if a Constructor was called already and what is happening is you are creating another instance of the control which isn't attached to the messages. I can see this happening if for example you used TFORM1.Create instead of TFORm1.CreateNew or even use the TApplication way of doing it, both will call the "Create" and not the CreateNew. The difference is that "Create" goes out and reads the resource file and gathers all the events that are actually allocated for the Host app. The fact that you are receiving data indicating that the class is already registered tells me that this is happening.. How else do you think the class would already be registered to the DLL module handle otherwise ? This is only an assumption on my part but it sounds plausible. |
|
|
You sound realistically. But I search all the code inside lcl/interfacace/win32, and the only call of this class registration is at that place. Also, if I removed a TComboBox in a host application form, it will return FALSE. If you are right, there will be no matter if there is or there is not TComboBox in a host application form active. I still think there is a bug inside Windows API and they thread DLL Hinstance as a host app hinstance. I had similar problem with a dll library load/unload in host and my dll. For example: If I load a library (open sll in my case) in host application and after that try to load the same library in my DLL, it will not load, it use the dll loaded from host application. And When I unloaded it from DLL, it fucks opensll in host app. https://www.atozed.com/forums/thread-1936.html |
|
|
I just spent some time building a host test app and a DLL to go with it.. I have a button and Combobox on the form of the Host app... In the DLL, I also have a Combobox on that too, both have contents within them.. I defined the OnChange event of the Combobox in the DLL and that works. I defined the OnClick event of the mouse for the Form in the DLL and that works.. EDIT: It appears during PAINT session the WM_DRAWITEM is not going to the correct window it appears for the Drop down window which has a different handle. I don't believe this has anything to do with class names, its just an effect to get around an issue not properly covered so using one hack to fix what is still a bug somewhere for DLL use is a bad idea. this needs to be researched more for the List box which is where the issue is. the events for the combobox seem to be working just fine as does the host app too.. I loaded the DLL at runtime with a button instead of the static method because for some strange reason the host app bombs when trying to load it .. I haven't yet figured that one out. But the dynamic load at will seems to work.. This is the 64 bit target I did this on. I can post the two projects here if anyone is interested. |
|
|
@Jamie Please test the OnExit event both on list and combobox. In my DLL combobox I not receive "OnExit". If yoy are can not register class you will not register WndProc for this ComboBox. And the Combobox will not receive message (for examle WM_KILLFOCUS which must trigger "OnExit" ). The same for ListBoxControl. |
- Anonymous
