C / C++ / MFC

2-Jun-04 22:09

I have developed a MFC program (MFC Dialog) which uses the USB port for getting joystick data using the Joystick messages.

Now would it be possible to use this code in a DLL, i.e. define DLL functions to hide/show the Dialog and obtain the Joystick data.

I used the Dialog to display what Joystick buttons was pressed and display the x, y and z data of the Joystick together with any errors (e.g. Joystick not detected) which was useful.

What I think I want is to have access to Joystick data via a DLL interface but have the DLL act like a MFC program when required.

What I dont want is to have to include this dialog into any applications that require Joystick data.

I have used the Joystick messages JOY1BUTTONUP, JOY1MOVE etc in the dialog.

What are the pitfalls?

John R. Shaw2-Jun-04 22:24

2-Jun-04 22:24

This makes no since! You wrote a program (dialog based) that interpits joystick messages.
sweep123 wrote:
What I dont want is to have to include this dialog into any applications that require Joystick data.

Well, do not include it; the dialog application was a test! Now you can write the real application knowing that you do receive the messages and can act accordingly.

INTP

sweep1232-Jun-04 22:35

2-Jun-04 22:35

What I was trying to obtain, is it possible to wrap up this dialog based MFC application into a DLL so that any other programs that require Joystick input could use this DLL.

Now if any applications have problems during debugging you could call upon the facilities of the Joystick DLL to aid testing. i.e. display the dialog and view the Joystick data and status info.

Also would it be possible for a Console based application to use this DLL (which contains a dialog and message maps etc).

Yes I could use the code by inserting it into each project, but just wanted to re-use in the simplest way possible the code already generated.

Does that make more sence?

John R. Shaw2-Jun-04 23:43

2-Jun-04 23:43

Ok! Break the code down! One message per function (like MFC does)! You need to seperate the code that displays the messages from the code that interprets the messages.

If you want to give (your DLL) the ability to show the last message received, then you will have to provided some storage space (i.e. variables) to hold the last message received.

The dialogbox is irrelivant, the information is what matters. Seperate the information functions (totaly) from the interface. Then the information can be retrieved, regardless of what interface is used to display it.

INTP

sweep1233-Jun-04 0:30

3-Jun-04 0:30

I think my real question is can I just build my MFC application as a DLL where I export several functions that provide Joystick data/status. Yes seperate the code that displays from the code that manages the data.

But when I load this DLL, will the dialog be displayed? I was thinking of having a hide/show function exported via the DLL.

What confuses me is that fact that as I dont want to use DirectX for Joystick control, just want to use the Joystick messages, but does that mean I need to have a dialog etc to run this scheme?

Or can I still use the Joystick messages in the DLL without creating an MFC type program with dialogs etc.

John R. Shaw3-Jun-04 1:35

3-Jun-04 1:35

The dialog should be just another function that you call. In order for it to display the infomation it has to call the same functions that an external program would have to call. If the data source is seperated from the code that displays the data, then anybody can access the data. For example document->view; the document is the data the view is the display. You could have one view show the data as a line graph and another as a bar graph, they all are getting the data from the same source.

As to whether you can bypass DirectX for Joystick control messages, I do not know. I suspect you cann't.

sweep123 wrote:
But when I load this DLL, will the dialog be displayed?
No!

sweep123 wrote:
can I still use the Joystick messages in the DLL without creating an MFC type program with dialogs etc.
Yes!

MFC is just a frame work provided by Microsoft. It is not the key to writing Windows programs, the key is the Windows SDK which was written in C. MFC just make it easier to write programs for Windows. Try to write your code as MFC independent as possible, use MFC mainly for the interface.

INTP

sweep1233-Jun-04 2:31

About nmake and vcvars32.bat

3-Jun-04 2:31

Thanks for your input.

I think I will re-write the code as a DLL, lifting as mush as possible from the MFC application.

May even post it if it all works OK.

Thanks again.

Filomela2-Jun-04 22:03

Filomela

2-Jun-04 22:03

when i run vcvars32.bat i get the following message: out of environment space.
when i try to run the command: namke /f makefile.w32 zlib.dll i get a fatal error: V1073: don't know how to make adler32.c.
this code is taken from codeguru->visual c->misclaneous->miscellaneous->MAPI->send as zip.I need this code for my progrm.

Re: About nmake and vcvars32.bat

David Crow3-Jun-04 4:24

David Crow

3-Jun-04 4:24

Filomela wrote:
when i run vcvars32.bat i get the following message: out of environment space.

I've not seen this problem since DOS and Windows 3.1 were the norm. What OS are you using? Read MSDN articles Q248802 and Q230205 for starters.

"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen

Re: About nmake and vcvars32.bat

Filomela3-Jun-04 21:04

Filomela

3-Jun-04 21:04

I'm using Windows 98.

PreTranslateMessage problems

Aviv Halperin2-Jun-04 22:02

Aviv Halperin

2-Jun-04 22:02

Yesterday I asked in this forum about a problem:
I could never get the PreTranslateMessage in my dialogs.

I found a solution:
for my current project I use MFC in a dll (staticaly linked).
I had to give an interface to the application that starts the dll an overide the PreTranslateMessage function of the application to call the interface function that activates the PreTranslateMessage mechanism.

Aviv.

Re: PreTranslateMessage problems

John R. Shaw2-Jun-04 22:44

Re: PreTranslateMessage problems

2-Jun-04 22:44

I was not here yesterday; but in general, you do not want to staticaly link to the MFC DLL (mass overhead). I have more than one class that overides the PreTranslateMessage function and none of them required that MFC be staticaly linked. For that matter PreTranslateMessage was disigned to be overriden, that is, it is a member of the CWnd class which is the base of all window based objects.

INTP

Aviv Halperin3-Jun-04 0:04

Aviv Halperin

3-Jun-04 0:04

Linking the dll dinamicaly to MFC would not solve the problem.
(I checked out the microsoft sight about this. Look at the DLLScreenCap Sample at this URL :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcsample/html/vcsamDllScreenCapSample.asp
)

The problem with the PreTranslateMessage is, that it was not passed through to the dll automaticaly, but needs to be done manualy.

avivhal

Re: PreTranslateMessage problems

John R. Shaw3-Jun-04 0:50