DLL Form and MS Access

[David Maruca]

Hey everyone! This is my first post here and I'm thrilled to be a new member of the FF and PB community.

Problem:

• I created a dll test with a form in 3.07. All settings are default. I made a small wrapper to open the form (code below) and store the parent hwnd. Works great. The caller is an MS Access database. The problem is that when I close the dll form it closes MS Access. How can I prevent this?
• I also wonder if there is a way to get this dll form to show up in the taskbar and alt-tab. Any suggestions?

Simple export wrapper:

Code Select Expand

Function Showwin Alias "Show"(Byval hwnd As Dword) Export As Long
    hwndParent = hwnd
    Function = FORM1_Show(hwnd, %FALSE)
End Function

Background:
Right now I work with MS Access at my job with a team of 3 others automating thousands of reports (not an exaggeration). MS Access wouldn't have been my first choice to handle this, but it was given to me and there was already a large code base when I was hired, so I am working with it. One of the reasons I bought PB and FF on my own dime was so I could get around some limitations imposed by my environment and to create dll procedures when I need extra speed. One of the problems I run into with Access and the lack of admin rights is not being able to install and work with com objects simply because they can't be registered or installed without going through 2 weeks of red tape. I could do that for my machine, but then I would also have to do it for all of the deployment machines. Way more trouble than it is worth. PB and FF handle this problem beautifully being able to work with just about anything without it being a registered com object. I am loving these tools so much. I've only been using them for a short while and have already learned so much more about windows programming than I have using any other environment.

[Brian Chirgwin]

Not sure if this will help, but download the attached project:

. The PB form has a property called export. I set this to true in the project. No wrapper is required.

. I hard coded the path to the project in the access db module as "C:\testdb\testdb.dll" you will need to change this. You can set the path statement or store the dll in Windows directory.

. There is a form in the access database. Open the form and click the two buttons. This calls two different functions that are in the attached DLL. Form1_Show and HelloWorld.

. The Module in the access database contains the declares to the functions in the PB written testdb.DLL.

. Not sure if this is the direction you are headed. You can pass information from the such as mdb path or data to the DLL to be used in developing reports.  The dll could acccess mdb data via odbc connection or data being passed into it. Since your going this far, why not just build a PB UI to the access data(mdb) file. Maybe this is your plan after some testing and approval.

If I've misinterpreted your questions, please post a sample the project and I can take a look.

[David Maruca]

Thanks very much for the reply, Brian. I loaded your codegen include in winmerge and compared it to mine, and it looks like FireFly added the line "PostQuitMessage 0" to my %WM_DESTROY. I don't see any options that I set that would cause it to add this line of code. I can comment it out and recompile it using pbwin and it will no longer cause access to close.

Maybe Paul Squires could chime in about this. Did I discover a bug? I posted the project and a test database like you did, Brian. You can run it and check it out for yourself. I set up a wndproc hook in access so I could relay messages from my pb form.

Brian, Interestingly enough you had your pb form set to show modal using True in vb and the form's hWnd from Access. This didn't cause the form to really be modal. True in VB equates to -1 and it seems PB wants 1. I also changed it from Me.Hwnd to Access.hWndAccessApp and I then got the desired behavior.

Now all I need to do is figure out how to get the form to show up in the taskbar. I guess I can check it out using winmerge again tomorrow with an exe generated form.

Edit: The dll in the included zip was compiled with the PostQuitMessage commented out. You can open and recompile with FF3 and the postquitmessage behavior will persist.

Edit2: Mr Squires, the codegen for the form1 create also differs from Brian's in the "If ShowModalFlag = %TRUE" block. Brian's code shows

Code Select Expand

    If ShowModalFlag = %TRUE Then
       '...edit
    Else
       [b]ShowWindow hWndForm, %SW_SHOWNORMAL[/b]
       Function = hWndForm
    End If

and mine shows

Code Select Expand

    If ShowModalFlag = %TRUE Then
       '...edit
    Else
       'The function call is missing...
       Function = hWndForm
    End If

[David Maruca]

Paul, I think I remember what I did that might have caused the codegen behavior difference. I was playing around in my project with adding and removing an MDI form. I think this could have caused some type of internal project flag to be set that would make it add the postquitmessage? I don't seem to be able to recreate it in Brian's project... I will have to recreate my project to get it to stop doing postquit. No  big deal.

[David Maruca]

Ok, I found out what was causing firefly to add the postquitmessage to the Output code. It didn't have anything to do with MDI forms that I was playing around with. It's because my form was set as the startup form in the firefly ffp file.

Code Select Expand

[Objects]
Form=.\forms\Form1.frm|0|0|Startup

Interestingly enough, I can't set the form as the startup form through the GUI since this is a dll project, so I don't have any clue how it got there.

[Paul Squires]

hmmmm.... interesting. Thanks David for investigating this problem. I'll make the changes tomorrow and send a new package for you to test.

Sorry for the trouble - we'll get it all fixed up as soon as possible.

[Brian Chirgwin]

Ok, I found out what was causing firefly to add the postquitmessage to the Output code. It didn't have anything to do with MDI forms that I was playing around with. It's because my form was set as the startup form in the firefly ffp file.

Code Select Expand

[Objects]
Form=.\forms\Form1.frm|0|0|Startup

Interestingly enough, I can't set the form as the startup form through the GUI since this is a dll project, so I don't have any clue how it got there.

Did you create the form in a exe project and load it into a DLL project later? That's all I can think of.

[David Maruca]

Did you create the form in a exe project and load it into a DLL project later? That's all I can think of.

No. It was just an empty project created to test making dll forms.

[Paul Squires]

How were you able to able to designate Form1 as the Startup form? When I create a DLL project, the only option in Project Properties is FF_AppStart.

[Paul Squires]

Oh, right, I just re-read your email message... you don't know why it happened. Hmmm...not sure why it would happen. I'm puzzled.

Maybe manually edit the project file and change this line:

Form=.\forms\Form1.frm|0|0|Startup

to...

Form=.\forms\Form1.frm|0|0|0

[David Maruca]

I did manually edit the project file and it solved the problem.