open child-windows located in a dll

[Christian Weilguny]

Hi,

after I've gained expirience with my problem (mdi-child located in dll), I've decided to deal with "normal" childwindows.
This works fine if I use a main-program generated with the pb-ide (the dll may be designed by FF, there I have only to use a SendMessage instead of FF_Close), but it fails using a main-program generated by FF. Then the whole program hangs by clicking on the first control of the childwindow and have to be removed by taskmanager. This behavior is not consistent, sometimes I can click the close-button and the window closes correct. But clicking on a textbox or a listbox and so hangs the program every times.

What can be wrong?

I use "LoadLibrary" to get a handle for the Lib, "GetProcAddress" to get a handle to the function within the Lib, that opens the childwindow and call this function by "CALL DWORD hdl USING ....".

This opens the childwin correct and I can resize it by code (the style of the window is not resizeable by user).
When I click on  any control it hangs in most times (except clicking on the close-button or some other butten with code for the BN_Click-event, without code there it hangs also).

Christian

[Paul Squires]

Hi Christian,

I will work up an example today and post it. I have never been a big fan of using GUI forms, etc, in DLLs but several FF3 customer do so all the time (actually, they us VB and call the Forms from a FF3 DLL).

I'll report back here once I test this all out for myself.

[Christian Weilguny]

Hi Paul,

thanks very much.

Please notice, with modal forms it's all right, but childforms make the program hanging. I do not know, if the problem with MDI-Childs is the same, but the symptoms are the same. Fortunately I need only Childwindows.
I forgot to write, if the close-button has the FF_Close.. - Function in code, the childwindow closes and the mainwindow closes too. If I use SendMessage with %WM_Close only the childwindow closes.

Christian

[Paul Squires]

I use "LoadLibrary" to get a handle for the Lib, "GetProcAddress" to get a handle to the function within the Lib, that opens the childwindow and call this function by "CALL DWORD hdl USING ....".

I am not sure why you need to do that. All I do is set the "Export" property for the form in the DLL to "True" and create a reference to it in the parent application (eg. Declare Function frmChild_Show LIB "CHILD.DLL" Alias "FRMCHILD_SHOW"........).

I have noticed from my simple test that FF3 is generating a PostQuitMessage in the WM_DESTROY handler for the child form in the DLL. This is a problem because it closing the main application. I will post a modified FF3 exe that corrects the problem

[Paul Squires]

Please notice, with modal forms it's all right, but childforms make the program hanging.

I assume that you mean child forms that are shown non-modal. I just tried it and I did not experience any hanging but I did notice that the TAB key does not move the focus from control to control (probably because the message loop is in the main exe).

[Paul Squires]

Attached are the two sample projects. One for the parent application and one for the child dll application. I have also attached the fixed FF3.

I doubt that MDI child forms will work in the DLL. Not sure why you would even want to do that.


[attachment deleted by admin]

[Christian Weilguny]

Not sure why you would even want to do that.

If I do so, I have the following possibility:

There is a main-exe, containing all logic for program-flow.

And there are one, two or much dlls, containing data-access and moduls providing functions to the mainprogram.

If I want to add a module, I first extend a table in a database with one recordset, holding the name of the dll and the name of the exported function and second copy the dll in the programroot.

The mainprog opens the table, read all records, fill a TreeView (or ordinary menustructure)  with this data and I have a "runtime-extended" application with no need to recompile the mainprog for each update.
Also it's possible for Third-Party-Developers, to extend the program with their own menus without need of recompilation of the main-exe or any other modul.

Thanks very much for posting the samples and the changed FF.exe.

Christian

[Christian Weilguny]

All I do is set the "Export" property ....

Sorry, I'm very new to FF3.
There exists an "Export"-Property for Forms? I have not seen it  .

On the other hand I need in mainprogram ONE and only ONE declaration for all forms in all modules (especially with the same ALIAS-Name). So I have to create my own procedure, calling the "Form_Show" of FF. And calling in mainprogram by DWORD USING ..., whereby I can use the same prototype for all called Forms (there is no necessary to put the name of the Lib in the prototype).

Christian

[Christian Weilguny]

Hi Paul,

when I modify your samples to use CALL DWORD, it works fine if the childwindow is set to POPUP-style.
If i set it to CHILD, the application hangs, also using your call to the DLL.

Christian

[Paul Squires]

Are you trying to modify the WS_POPUP and WS_CHILD styles on-the-fly? I have attached the parent and child projects again showing that the form in the child DLL can indeed be used as a child control in the parent exe. Hopefully it will help point you in the right direction.

[Christian Weilguny]

Hi Paul,

this works and I know, what was wrong finally.

If the Childwindow has Titlebar and is moveable, it will be shown, it will be moveable, but the access to the controls on it is restricted.
Becouse I had ever a style with Titlebar, I had ever problems. The program doesn't hang (I don't know, why this happened) but there is no possibility to switch with TAB between the controls and text is not marked by doubleclick and so on.

What you mean with "on-the-fly" ? By code at runtime?

Christian 

[Christian Weilguny]

Now I know, why the program hanged by CALL DWORD ... 

In the exported procedure had the call to Frm_Show the ShowModalFlag set to true.
The compiler took it. Windows not.

Christian