Compiling to DLL

Started by Martin Francom, February 12, 2010, 10:58:09 PM

Previous topic - Next topic

Joakim Schramm

Quote from: TechSupport on February 16, 2010, 09:56:26 AM
Quote
[Objects]TopTab=#FF_WinMain#|True|True|0|41
Yes, that only makes it show up in the editor as a tab.

A follow up question on this. I tried an put that line into my project file but it just loaded a "bare" FF_LIBMAIN, and not the one I have in my project file? Also I tried to edit and save it, as I have some important clean up in %DLL_PROCESS_DETACH, but on next reload of project same bare FF_LIBMAIN is back in Tab, although my original still remains in the project file... I am a bit confused, in FF2 it was possible to edit this function but appear to be not so anymore? I tried to change #FF_WinMain# to #FF_LibMain# (as in FF2) but it only had the effect no tab was shown.

Paul Squires

There does seem to be a problem with the FF_LIBMAIN not saving changes to the disk. It always seems to be creating a new, blank FF_LIBMAIN when the project loads. I will fix that today.
Paul Squires
PlanetSquires Software

Paul Squires

This may also be a long shot, but are you restarting the VB environment after you make the changes to the DLL ?? I remember that the VB environment would not always release any DLL's in use until VB was shutdown. This was evident to me when I used to try to use the Cheetah Database DLL in VB (especially when doing the p-code compile/run rather than the full compile to an exe).

Paul Squires
PlanetSquires Software

Joakim Schramm

Quote from: TechSupport on February 16, 2010, 12:31:48 PM
There does seem to be a problem with the FF_LIBMAIN not saving changes to the disk. It always seems to be creating a new, blank FF_LIBMAIN when the project loads. I will fix that today.

Also check this,

it appears as if
TopTab=#FF_WinMain#|True|True|0|41
is created some times but some times not, in project file when creating a new DLL project.

Joakim Schramm

Quote from: TechSupport on February 16, 2010, 12:37:38 PM
This may also be a long shot, but are you restarting the VB environment after you make the changes to the DLL ?? I remember that the VB environment would not always release any DLL's in use until VB was shutdown. This was evident to me when I used to try to use the Cheetah Database DLL in VB (especially when doing the p-code compile/run rather than the full compile to an exe).

I don't run test in IDE but in compiled exe in VmWare container with XP, so shouldn't be it. Meanwhile, I have done some tests with other dll that not uses any forms, recompiled in FF3 and PB9, to ensure it works ok - and it does.

So now I will test to recrate my dll project using form.

Joakim Schramm

#20
I have had some success  :)

Not ready rebuilding it all yet but I did a small test after adding all module code and a form, just adding a few of the controls and load it with my ViewAtlas function. Form now loads from VB6 at least although when closing it takes the whole app with it down - but that's probably not of any big importance now and can probably have its "natural" causes.

EDIT: After all controls added and windows styles set so form now is identical, except no code added it still loads.

Joakim Schramm

Ok I have spotted it, it's in my code but I don't understand why this gives a GPF when compiled in FF3 but not in FF2

the evil line of code is
LSet uCurrPlace = trm_GetDirect(hAtl, StrListItems(FF_ListBox_GetItemData (HWND_FRMATLASVIEW_LSTPLACES, CurrPlaceSel)))

in
Function FRMATLASVIEW_LSTPLACES_CUSTOM ( _
                                       ControlIndex  As Long,  _  ' index in Control Array
                                       hWndForm      As Dword, _  ' handle of Form
                                       hWndControl   As Dword, _  ' handle of Control
                                       wMsg          As Long,  _  ' type of message
                                       wParam        As Dword, _  ' first message parameter
                                       lParam        As Long   _  ' second message parameter
                                       ) As Long
Select Case wMsg
    Case %LB_SETCURSEL
        CurrPlaceSel = wParam
        LSet uCurrPlace = trm_GetDirect(hAtl, StrListItems(FF_ListBox_GetItemData (HWND_FRMATLASVIEW_LSTPLACES, CurrPlaceSel)))
        UpdateFields
        UpdateLatLng
    End Select

End Function


StrListItems is a dynamic string array with global scope, to make it clearer but that shouldn't really matters.
Just thought I would post it while figuring it out as the answer probably exists somewhere near by ;-)

Joakim Schramm

Just want to add that it's jittery strange, because exact same line if code exists in
Function FRMATLASVIEW_LSTPLACES_LBN_SELCHANGE ( _
                                              ControlIndex  As Long,  _  ' index in Control Array
                                              hWndForm      As Dword, _  ' handle of Form
                                              hWndControl   As Dword, _  ' handle of Control
                                              idListBox     As Dword  _  ' identifier of listbox
                                              ) As Long
CurrPlaceSel = FF_ListBox_GetCurSel (HWND_FRMATLASVIEW_LSTPLACES) 
LSet uCurrPlace = trm_GetDirect(hAtl, StrListItems(FF_ListBox_GetItemData (HWND_FRMATLASVIEW_LSTPLACES, CurrPlaceSel)))

UpdateFields     
UpdateLatLng
FF_Control_SetFocus HWND_FRMATLASVIEW_TXTPLACE

End Function


but if doesn't cause a GPF, only differance is that the evil one is inside a select case clause. Huuh

Paul Squires

Hi Joakim,

The code two post prior to this one is wrong. You should be testing for WM_COMMAND in the CUSTOM and not for the %LB_SETCURSEL message. LB_SETCURSEL is sent to the ListBox to set the selection. It is *not* received by the Form indicating that a change on the listbox was made (that is what the LBN_SELCHANGE notification does) - these are two totally different messages.

This is wrong:

Function FRMATLASVIEW_LSTPLACES_CUSTOM ( _
                                       ControlIndex  As Long,  _  ' index in Control Array
                                       hWndForm      As Dword, _  ' handle of Form
                                       hWndControl   As Dword, _  ' handle of Control
                                       wMsg          As Long,  _  ' type of message
                                       wParam        As Dword, _  ' first message parameter
                                       lParam        As Long   _  ' second message parameter
                                       ) As Long
Select Case wMsg
    Case %LB_SETCURSEL
        CurrPlaceSel = wParam
        LSet uCurrPlace = trm_GetDirect(hAtl, StrListItems(FF_ListBox_GetItemData (HWND_FRMATLASVIEW_LSTPLACES, CurrPlaceSel)))
        UpdateFields
        UpdateLatLng
    End Select

End Function


This should work (but using the LBN_SELCHANGE message handler like in your previous post is a better choice):

Function FRMATLASVIEW_LSTPLACES_CUSTOM ( _
                                       ControlIndex  As Long,  _  ' index in Control Array
                                       hWndForm      As Dword, _  ' handle of Form
                                       hWndControl   As Dword, _  ' handle of Control
                                       wMsg          As Long,  _  ' type of message
                                       wParam        As Dword, _  ' first message parameter
                                       lParam        As Long   _  ' second message parameter
                                       ) As Long
Select Case wMsg
    Case %WM_COMMAND
       If HiWrd(wParam) = %LBN_SELCHANGE Then
          If lParam = HWND_FRMATLASVIEW_LSTPLACES then
             CurrPlaceSel = FF_ListBox_GetCurSel(HWND_FRMATLASVIEW_LSTPLACES)
             LSet uCurrPlace = trm_GetDirect(hAtl, StrListItems(FF_ListBox_GetItemData (HWND_FRMATLASVIEW_LSTPLACES, CurrPlaceSel)))
            UpdateFields
            UpdateLatLng
        End If
      End If
    End Select

End Function

Paul Squires
PlanetSquires Software

Joakim Schramm

I think I have figured it out finally! Some how, only when compiled in FF3, Function FRMATLASVIEW_LSTPLACES_CUSTOM is trigged twice during load of the form with the message wMsg = %LB_SETCURSEL, while one of them is by my code after some data been initialized and listbox filled, it appear to happens once before my call which break things.

Can this be due to the loading of controls you mentioned before Paul? But it cannot be just it as I did disbled that code before and made a test compile. Apart from it always being nice to learn what really causing issues like this, it's not anything major that I cannot easily code around, so to know exactly what triggers the event message would be good. It's clear though that it happens before I even fill up the listbox with data as if I set Listbox.InitialSelection to index 0 it return -1 for Itemdata which I only asign positive intergers to. Hmmm

Joakim Schramm

Quote from: TechSupport on February 16, 2010, 06:07:49 PM
Hi Joakim,

The code two post prior to this one is wrong. You should be testing for WM_COMMAND in the CUSTOM and not for the %LB_SETCURSEL message. LB_SETCURSEL is sent to the ListBox to set the selection. It is *not* received by the Form indicating that a change on the listbox was made (that is what the LBN_SELCHANGE notification does) - these are two totally different messages.

Yes probably I do something wrong but let me explain _why_ I do it. After loading the listbox with data I do an initial selection, which may vary from time to time, in other words it's a dynamic value. It was quite some time since I wrote the code so don't remember exactly but have a vague memory I wasn't able to use LBN_SELCHANGE and I think I got help or input for it in the old forum.

If there is a better way to do it. I am eager to learns and well I am not that at home with this API programing style although I guess one gets used to it as time passes by.

Joakim Schramm

And may I add that your code worked, of course, GPF is gone - Thank you Master :D

Now there is another problem in that when I close the form it takes with it down the whole of my VB app, but if I don't manage to figure that out I will open a new threed.

Paul Squires

Quote from: Joakim Schramm on February 16, 2010, 06:46:35 PM
Thank you Master :D
hmmmm..... I think I can used to that! Maybe we should make it mandatory that everyone end their posts with that phrase! :) :D
Paul Squires
PlanetSquires Software

Paul Squires

Joakim,

I am going to email you a new FireFly3.exe that fixes the FF_LIBMAIN problem of it not saving the code to the project file.
Paul Squires
PlanetSquires Software