Click to See Complete Forum and Search --> : dll program


sachin_dm
September 20th, 2002, 07:44 AM
hi friends,

i'm using BC++ 4.5 (target 16-bit) to develop a program
which writes data entered in edit boxes to an ini file with
WritePrivateProfileString
i'm printing the same data using GetPrivateProfileString
and then TextOut
the program works fine when i create .exe

(i've created dialogs in .rc files )
but when i create a 16-bit dll with LibMain

tab stops and hotkeys (alt+c), enter key, space bars
are not working with the dialogs which are into .dll

also the printing functions are not working properly. i.e.
it prints everything except the data that i'm getting with
GetPrivateProfileString into a static array of characters

and i've to use it in the main software (which is already there with
our client)

1) what's wrong with the dll?
2) why tab button and enter key, space bar are not working?
3) Is there anyway that i can call an exe thru main program?
I know WinExec
but i don't want to show the window of the called exe



thanks in anticipation for any help

regards,
Sachin M

JMS
September 20th, 2002, 05:59 PM
>> 1) what's wrong with the dll?

Short answer....

Your probable not using the right "type" of DLL.. read up on extension dlls... Normal dlls are typcially used for none windows classes.

Longer Answer.....

Putting myself in the way back machine........ DLL's back in 16 bit DOS world had a drawback.... It became a nerveous tick for those of us old enough to remember... "DS != SS". Which translates to Data segment not equal to Static Segment. This is a good thing because it allows different processes to be able to utilise the same instance of a DLL in memory... once again in 16 bits and in the way back machine... But this is also a bad thing, it's a bad thing because little things like Windows instance handles which all Window programs require wont work in a dll by sesign. They get hosed up since the dlls are..(were) designed to work single instance multiple processes..

Why this is still important today is because when Microsoft designes something way back, it usually remains if not true but shall we say influencial.

If you wish a DLL to contain a window it must be a specific type of DLL called and Extension DLL which incorporates the Instance handle of the process.

>> 2) why tab button and enter key, space bar are not working?

IT's probable also related to the fact that "Instance handles" are not valid in normal DLLs. You can verify this by using the Debugger and stepping into the MFC code. Where it calls for an instance handle you'll note it's NULL. Once again using an extension dll should fix your problems..

>> 3) Is there anyway that i can call an exe thru main program?
>> I know WinExec but i don't want to show the window of the
>> called exe

If you don't want to show the called exe then use WinExec with the SW_HIDE command.


Goodluck..

Nati
September 24th, 2002, 04:45 AM
I do not know about 16 bit dlls, but in 32bit MFC 5 & 6 if you have a window in a regular dll it does not recieve general notifications like tab, ctrl+c, ctrl+v etc..

In order to handle this events you have to catch them in the PreTranslateMessage stage of the main event loop and pass them to the dll by yourself.
This is because the regualr dll has a different CWinApp object.

The following quate is taken from MSDN
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcsample/html/vcsamDllScreenCapSample.asp

A non-extension DLL that is linked to the MFC library needs to have a CWinApp-derived class and a single object of that application class, as does an executable MFC application. The CWinApp object of the DLL, however, does not have a main message pump, as does the CWinApp object of an application. If the DLL opens modeless dialog boxes or has a main frame window of its own, the application's main message pump must call a routine exported by the DLL, which in turn calls the CWinApp::PreTranslateMessage member function of the DLL's application object.