Paul,
Can you explane the do's and don'ts of this new feature:
Quote
- 0000697: [New Feature Request] Allow DLL FireFly projects (similar to FireFly Version 2) (Paul Squires) - closed.
Can child forms for the main program be put in the DLL and then called by the main program?
I assume a FF3 DLL should not contain a FrmMAIN but it can have popup forms and child forms that can be called by the main program. Correct?
Quote from: Marty Francom on February 12, 2010, 10:58:09 PM
Can child forms for the main program be put in the DLL and then called by the main program?
Yes, similar to FF2. Create your Forms and set the "Export" property for the Form to "True". You would then create a Declare statement in your main exe code to call the _Show function of the Form in the dll.
Quote
I assume a FF3 DLL should not contain a FrmMAIN but it can have popup forms and child forms that can be called by the main program. Correct?
Correct.
This feature may come in handy for large projects like the one I am currently working on. I never used the FF2 version of this feature. So I am interested on how this works.
Hi guys,
may I chip in on this threed as well? I have a dll with a form that compiled in FF2 and it then worked fine to call that dll's form from VB6 but after compiling the same dll in FF3 (after successfull import) I now get a GPF when calling the form in dll. As I just (re-)upgraded to FF3 (after Paul took the great decision to reimplement DLL project) I haven't had time yet to go through everything, so wonder if there is anything particullary "sensitive" that have changed between FF2 and FF3 regarding forms?
I had missed the export property, but GPF remains also after setting it to True. It's late here now so will continue exploring tomorrow but just thought if there might be something "obvious" I have missed in the the FF2 to FF3 transition? I also just upgraded to PB9 but I doubt that could be the problem although one never knows, so I will test compiling with PB8.04 as well tomorrow.
I know this is a PB and not a VB type of forum, but my app is too big to easily convert to PB, so I'm taking it gradually cutting down on VB code by moving it to PB dll's. So I hope this is ok as "on the stack" this all about Basic programing ;-)
My VB6 declaration looks like this
Declare Function ViewAtlas Lib "acjAtlasEx.DLL" (ByVal hParentForm As Long, StrCountry As String) As String
and I call it like this in a button click event
Dim sRecord As String
Dim sLocation As String
sLocation = txtPlace.Text & ":" & cboCountry.Text
sRecord = ViewAtlas(Me.hWnd, sLocation)
In FF3 I then has this code
Function ViewAtlas Alias "ViewAtlas" (ByVal hParentForm As Long, StrCountry As String) Export As String
Local nReturn As Long
Local StrReturn As String * 94
sCapText = GetString(28)
sInfoText = GetString(29) + $CrLf + $CrLf + GetString(30) + $CrLf + $CrLf + GetString(31) + $CrLf + $CrLf + GetString(32)
CurrPlace = Extract$(1, StrCountry, ":")
CurrCountry = Remain$(1, StrCountry, ":")
nReturn = FRMATLASVIEW_Show(hParentForm,%TRUE, 1&)
'MsgBox "CurrCountry " & CurrCountry ,,"DEBUG"
If nReturn Then
Type Set StrReturn = uCurrPlace
Function = StrReturn
Else
Function = ""
End If
End Function
while I (at least for now) wont post the full form code, this simple example is enough to trigger the GPF (everything else taken out), code runs fine up to the call to FRMATLASVIEW_WM_CREATE though.
Function FRMATLASVIEW_WM_CREATE ( _
hWndForm As Dword, _ ' handle of Form
ByVal UserData As Long _ 'optional user defined Long value
) As Long
Local Result As Long
Local NewIndex As Long
Local sRecord, sKey, sPlace As String
MsgBox "DEBUG " ,,"DEBUG"
End Function
So just by creating the form seem to be enough causing the GPF.
You talk about the _Show function Paul but I don't seem to be able finding any in my (from FF2 converted) form. I also tried to remove the WM_CREATE function in hope it would be recreated (with proper arguments) when I selected the form in code windows left drop down (like in VB6 IDE) but instead it simply jump to select another function of one of the controls that lives on the form, so now sure what's going on here?
EDIT: Stupid me, I call the forms _Show function in my exported ViewAtlas function but well GPF remains...
Not sure what the GPF would be at this stage. I don't have VB installed anymore so I can not test it.
I did create a one form DLL project and exported the Form1. I then created a simple PB exe to display the Form in the DLL:
#Compile Exe
Declare Function FORM1_Show Lib "Project1.dll" ( ByVal hwndParent As Dword, _
ByVal ShowModalFlag As Long, _
ByVal UserData As Long _
) As Long
Function PBMain() As Long
FORM1_Show 0, 1, 1
End Function
As a test, I wonder if you can display the Form in VB directly rather than going through your ViewAtlas function:
Declare Function FRMATLASVIEW_Show Lib "Project1.dll" Alias "FRMATLASVIEW_SHOW" ( ByVal hwndParent As Long, _
ByVal ShowModalFlag As Long, _
ByVal UserData As Long _
) As Long
... in your Button Click event:
FRMATLASVIEW_Show Me.hWnd, 1, 0
No, just get an error "Can't find DDL entry point FRMATLASVIEW_Show in acjAtlasEx.DLL" and then GPF
In VB this declare
Declare Function FRMATLASVIEW_Show Lib "acjAtlasEx.DLL" (ByVal hwndParent As Long, ByVal ShowModalFlag As Long, ByVal UserData As Long) As Long
and call in button click like this
Call FRMATLASVIEW_Show(Me.hWnd, 1&, 0&)
Export for form is True, although I realized in my original code I don't need it as the form never really is exported but used inside dll.
I ran a comparison with Beyond Compare, between FF2 and FF3 release folder and noticed quite many differances there. As I was smart this time and installed to other location then FF2 I have both old and new FF installed, so I will start over from scratsh and make a new comparison in a more prestine state. Obviously FF3 must do something differently that upset Windows. I tested with PB8 as well by the way, and no differance.
@ Marty: Sorry that I sort of hijacked your threed but I figured you basically had got your question answered and this should just built on top of the knowledge base for people coming later... So I hope you are ok with it mate?
Recompiled DLL project in FF2 using PB9.03 and confirmed it worked as expected. Copied the full FF2 project folder into where I have FF3 projects, opened it in FF3 and converted succesfully. As conversion leave old files in release (really needed as they are backed up in FF2_Backup anyway?) folder I emptied it. Compiled using PB9.03 and first observation is that dll compiled in FF3 is 12288 bytes smaller then when compiled in FF2!? It certainly looks as if something is left out?
The build files differs all as well, except for the .jfp file, I will try to desect the relevant parts as it would be too much to post, but in general all .inc files appear to have shrinked when compile in FF3
EDIT: Observation 2 (and this may be something), In FF2 project Startup Form/Function is set to FF_LibMain but in FF3 this is set to FF_AppStart. In the generated declares.inc both FF2/3 creates
Declare FUNCTION FF_LIBMAIN(BYVAL hInstance AS LONG, _
BYVAL fwdReason AS LONG, _
BYVAL lpvReserved AS LONG) AS LONG
but I don't find any declare for FF_APPSTART, can it possibly be an ops here in the converstion of dll project? DLL does load though and only creating the form seem to cause problem.
Declare.inc is 1 of only 2 files, also main.bas, that actually is bigger then generated in FF2. It may not be of importance but just note it down here.
Observation 3
Following up on previous post I wanted to see what values came up when creating a DLL project from start in FF3 and then notice it creates the module FF_DLLMain with
Function FF_LIBMAIN( ByVal hInstance As Dword, _
ByVal fwdReason As Long, _
ByVal lpvReserved As Long _
) As Long
Select Case fwdReason
Case %DLL_PROCESS_ATTACH
' Indicates that the DLL is being loaded by another process (a DLL
' or EXE is loading the DLL). DLLs can use this opportunity to
' initialize any instance or global data, such as arrays.
Function = 1 'success!
'FUNCTION = 0 'failure! This will prevent the DLL from running.
Case %DLL_PROCESS_DETACH
' Indicates that the DLL is being unloaded or detached from the
' calling application. DLLs can take this opportunity to clean
' up all resources for all threads attached and known to the DLL.
Function = 1 'success!
'FUNCTION = 0 'failure!
Case %DLL_THREAD_ATTACH
' Indicates that the DLL is being loaded by a new thread in the
' calling application. DLLs can use this opportunity to
' initialize any thread local storage (TLS).
Function = 1 'success!
'FUNCTION = 0 'failure!
Case %DLL_THREAD_DETACH
' Indicates that the thread is exiting cleanly. If the DLL has
' allocated any thread local storage, it should be released.
Function = 1 'success!
'FUNCTION = 0 'failure!
End Select
End Function
In FF2 project I have similar FF_LibMain module with FUNTION FF_LIBMAIN and this module appear to not been brought over when the project was converted from FF2 to FF3. Well it has in a way, it's in the project file just as the one created on new project but it never show up and get a Tab in the editor GUI. One thing I notice here as well is that the argument data type differs somewhat between the one created by new FF3 DLL project and the one converted.
In New project it's
[FF_WINMAIN_START]
Function FF_LIBMAIN( ByVal hInstance As Dword, _
ByVal fwdReason As Long, _
ByVal lpvReserved As Long _
) As Long
...
End Function
[FF_WINMAIN_END]
while in converted it's
[FF_WINMAIN_START]
FUNCTION FF_LIBMAIN(BYVAL hInstance AS LONG, _
BYVAL fwdReason AS LONG, _
BYVAL lpvReserved AS LONG) AS LONG
...
END FUNCTION
[FF_WINMAIN_END]
investigation continues...
Hi Joakim,
I'll do investigation today as well and I'll post here my findings. I'll do a project in both FF2 and FF3 to see exactly where the code changed (and why). We'll get to the bottom of this soon. There must be some small thing that is different that is causing VB to choke on the code.
Sounds good and I will certainly not stop digging either ;-)
Found this little differance in project file as well between the a new dll project and the converted
[Objects]
TopTab=#FF_WinMain#|True|True|0|41
exists in new project and probably what makes it show up in the editor tab. Not sure if it will have inpact on compile though. I can of course try to simply paste it into my converted project file but don't really know what |True|True|0|41 stands for?
Hi Joakim,
I found a few things that could be the trigger. Not 100% sure at this point:
- FF3 is generating a #Resource file reference whereas FF2 is not.
- The LibMain DWord vs. Long variable declaration that you noticed (although I can't see this being a big problem because they are both 32-bit integers).
- FF3 is initializing the common controls classes whereas FF2 is not.
The assignment of the App.hInstance in LibMain needs to be moved after the call to FLY_SetAppVariable.
- Using the PB Included vs. using Jose's includes (can't see this as being a problem either).
Maybe try commenting out the #Resource line and then try commenting out the code that initializes the common controls. You can then manually re-compile the DLL using PB9 and test it with VB.
Quote
[Objects]TopTab=#FF_WinMain#|True|True|0|41
Yes, that only makes it show up in the editor as a tab.
Quote from: TechSupport on February 16, 2010, 09:56:26 AM
Hi Joakim,
I found a few things that could be the trigger. Not 100% sure at this point:
- FF3 is generating a #Resource file reference whereas FF2 is not.
- The LibMain DWord vs. Long variable declaration that you noticed (although I can't see this being a big problem because they are both 32-bit integers).
- FF3 is initializing the common controls classes whereas FF2 is not.
The assignment of the App.hInstance in LibMain needs to be moved after the call to FLY_SetAppVariable.
- Using the PB Included vs. using Jose's includes (can't see this as being a problem either).
Maybe try commenting out the #Resource line and then try commenting out the code that initializes the common controls. You can then manually re-compile the DLL using PB9 and test it with VB.
Hmm how would I do that in a simple way? I can just admit I am stupid on that as I been so spoiled to let FF do it for me, specially as main portions of my projects still are in VB6 I simple haven't got that "serious" with PB, yet. I probably did it at the time when I first purchased PB8, but too much time has since been spent in VB6 pleasurous IDE ;-) so can you give a one liner or something? The code editing is no problem, there I am at home.
If that wont show it I am thinking of rebuilding the project from start in FF3 and just copy in my code and see if that works. A compare between the 2 sets of generated files should then pretty much make it stick out I think.
Quote from: TechSupport on February 16, 2010, 09:56:26 AM
- FF3 is generating a #Resource file reference whereas FF2 is not.
That's not correct by the way, FF2.99 at least does it.
Sorry, I'm an idiot, common ctrl init commented out and dll recompiled but problem remain so that's obviously not it.
Tried all your suggestions now but without success, so now I will rebuild the project as a new DDL project, rebuild form etc. and just copy in my code and see if that helps. It probably will turn out in the end just being because one small little tiny, but very important, detail.
I love computers and programming - it will keep me young forever! ;D
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.
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.
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).
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|41is created some times but some times not, in project file when creating a new DLL project.
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.
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.
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 ;-)
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
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
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
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.
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.
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
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.