Question about LibMain

[Egbert Zijlema]

Hi fellows,

I'm about to write my first DLL. Although I prefer EXEs, in this special case a DLL can serve 3 executables, almost doing the same thing. Many functions and procedures are exactly the same because of that.
My problem: I don't know how to use LibMain. Is it just an empty wrapper? And if not, do I have to include all the 'attach/detach' stuff in it?
Can someone provide me with a small example?
Thanks,

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[This message has been edited by Egbert Zijlema (edited March 09, 2001).]

[Eric Pearson]

Just put FUNCTION=1 in your LibMain and you'll be fine. You don't need anything else, unless you need to initialize/shut down something in your DLL when it is loaded/unloaded, such an DIMing arrays, etc.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Egbert Zijlema]

Thanks, Eric!
One more question: where do I #INCLUDE the declares for the functions and procedures, in the DLL itself or in the calling EXE?
Sorry guys. Forget this stupid question. It is DECLARE "funcname" LIB "libname"() AS <dataname>, of course!!!!!!
------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[This message has been edited by Egbert Zijlema (edited March 09, 2001).]

[Eric Pearson]

Don't forget the ALIAS clause! It's very important when you are building DLLs.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Semen Matusovski]

Honestly, easiest DLL doesn't include LibMain at all.

  #Compile Dll
  Function DoSomething Alias "DoSomething" (...) Export As ...
  End Function

------------------
E-MAIL: [email protected]

[Egbert Zijlema]

Thanks for all your help, folks.
To be honest, I'm rather disappointed about the effects: my executable is only 1 Kb shorter in length, but I need a 10Kb DLL to accomplish this.
In other words, using this DLL for 3 executables will cost me approx. 7 Kb of diskspace. That's not worth the effort, I think!?
Further questions:
#1. A few functions use global variables. Where to declare?
#2. Can CALLBACK FUNCTIONS reside in a DLL (what about DDT-vars, such as CBHNDL)?
#3. Can procedures (SUBs) reside in a DLL?
------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[This message has been edited by Egbert Zijlema (edited March 09, 2001).]

[Eric Pearson]

As you have found, moving a single function to its own DLL may be counter-productive if "size" is your primary concern. But the more functions you move to the DLL the better things will get, because the DLL has a certain amount of "fixed overhead".

1) GLOBAL variables can't be shared between a DLL and an EXE. GLOBAL variables are visible at the "module" level, not the "program" level. (BTW this can be a big advantage because it simulates a new kind of variable scope, which I think of as "regional".)

2) I know that API/SDK-style callback functions can reside in a DLL, but I'm not sure about the DDT CALLBACK.

3) Yes.

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected]nc.com[email protected]</A>



[This message has been edited by Eric Pearson (edited March 09, 2001).]

[Michael Mattias]

I don't know why a callback can't reside in a DLL, but I don't think you can get the proc address from a separately-compiled module using CODEPTR. You may need to use LoadLibrary/GetProcAddress. The help file does not say if CODEPTR is restricted to the current source module.

...

Hmm, I just tried this and you cannot use CODEPTR on a DECLARED external, so I guess that's that. (COmpiler error, undefined SUB/FUNCTION reference)

MCM

[Joseph W Murphy]

I Do not normally use LibMain. You must if multi-threading is a concern
I like to give my DLL's generic names like JEMC0001, JEMC0002, etc
and the functions inside JEMC0001_1, etc
I do not think Globals are shared across EXE-DLL but you can pass the address of the variable
A DLL can update a TextBox in an EXE using SetWindowText (after you pass the hWnd of the Text Box)
=============
When you 'Build the dialog:
CONTROL ADD TEXTBOX, hDlg, IdText&, "", 14, 21, 134, 12, Style&
And from within an EXE callback(like %WM_INITDIALOG or a Button Callback):
{ Now cbHndl = hDlg from above }
hWnd = GetDlgItem(cbHndl ,IdText&)
=============
I allow for the EXE to cancel the DLL with a DLL Global Variable

Here is psuedo-code example.

#COMPILE DLL "C:\MURPHY\JEMCDLL\JEMC0001.DLL"
#DIM ALL
#INCLUDE "C:\PBDLL60\WINAPI\WIN32API.INC"

Global gAbEnd As Integer
Global PD1() As Integer
        
#IF 0
Declare Function CancelDLL Lib "JEMC0001.DLL" Alias "JEMC0001_0" (Byval nDummy As Long) As Long
Declare Sub RunDLL Lib "JEMC0001.DLL" Alias "JEMC0001_1" (Byval hWndW As Long, Byval hWndD As Long)
#ENDIF

Function JEMC0001_0(Byval nDummy As Long) Export As Long
    gAbEnd = %True
    Function = %True
End Function
    
Sub JEMC0001_1(Byval hWndW As Long, Byval hWndD As Long) EXPORT
    Local sTxt1 As AsciiZ * 20
    Local nRetC As Long
    Local nPause As Long
    
    gAbEnd = 0
    If UBound(PD1) = -1 Then
        Call InitDLL
    End If
    
    sTxt1="Inside RunDLL"
    nRetC = SetWindowText(hWndW,sTxt1)
'   May not need the Sleep, but it seems to make the app communicate better
    nPause = 10
    Sleep nPause
    Do Some big Loop
        sTxt1 = Str$(nSomeCounter)
        nRetC = SetWindowText(hWndW,sTxt1)
'       May not need the Sleep, but it seems to make the app communicate better
        nPause = 10
        Sleep nPause
        
        If gAbEnd Then
'           Do Any Clean Up
            Exit Sub
        End If
    Loop
End Sub

Joe Murphy


------------------