Re: Serial Port Communication. - C / C++ / MFC Discussion Boards

thank you very much !!!!!!!!!!!!!!!!!!!!!!! Big Grin | :-D

Hi *.*

I have written an MFC application in MS Visual C++6. Now I want to compile it with a different compiler but the one from MS. Is there a way to compile the whole project with borland's c++ compiler?

Are there any other good (or even better) compilers you can recommend?

thanks

I once used the Borland CPP Builder 4 VC++ Project Conversion Utility on a simple VC6 MDI project just to test. Worked well. My version of Builder has MFC files that corespond to VC5, but that wasn't a big issue for the simple test app.

I'm looking for some documentation on serial port communication in VC++. Does MFC support it?

- john

Never mind, I'm a moron. However it wouldn't let me delete my previous message, so I'm just saying I figured it out (and feel stupid)

Now I really wonder what I missed. Is there a nice class for this?

Eric Hansen

ehansen@pmsi.cc

Is there a nice class for this?

Look at P.J. Naughter's Serial Port class right here on CodeProject.

I couldn't find any classes in MFC for Serial Port Comms back when I was looking (about one year ago) so I started to write one...but that project has been on hold for a LONG while now. Unfortunately I'm a bit short on time right now so I'm just going to cut up some of my code send it along, hope it helps (I've never posted code to one of these but I have a feeling this isn't going to be that easy to read Frown | :(

).

Opening a port:

if (portOpen)
{
return portHandle;
}
else
{
// Try to open the comm port
char str[30];
sprintf( str, "\\\\.\\COM%d", portNum );

HANDLE hCom;
DWORD dwError;

hCom = CreateFile( str,
GENERIC_READ | GENERIC_WRITE,
0, // comm devices must be opened w/exclusive-access
NULL, // no security attributes
OPEN_EXISTING, // comm devices must use OPEN_EXISTING
0, // not overlapped I/O
NULL // hTemplate must be NULL for comm devices
);
if (hCom == INVALID_HANDLE_VALUE)
{
dwError = GetLastError();
TRACE0("Invalid Comm Handle in openPort()\n");
// handle error
return NULL;
}
else
{
portOpen = true;
portHandle = hCom;
return hCom;
}
}

Example of writing to and reading a response from a comm port (setting baud rate etc):

DCB dcb;
fSuccess = GetCommState(portHndl, &dcb);
if (!fSuccess)
{
// Handle the error.
}
dcb.BaudRate = 9600;
dcb.ByteSize = 8;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT;
fSuccess = SetCommState(portHndl, &dcb);
if (!fSuccess)
{
// Handle the error.
}

//unsigned char lpData[140] = {1,0,0,16,85,0,1,0,0,0,0,0,0,0,0,103 };
DWORD numActual = 0;
OVERLAPPED osWrite = {0};
BOOL succ;
DWORD error;

succ = WriteFile(portHndl,
sendBuffer, //Data to write to comm port
sendBytes, //number of bytes to write
&numActual, //pointer to number of bytes written
&osWrite // pointer to structure for overlapped I/O
);

if (!succ)
{
error = GetLastError();
TRACE("Bad Comm Write: %d,%d\n",portHndl,error);
}
else
TRACE("Good Comm Write: %d,%d\n",portHndl,error);

succ = ReadFile(portHndl, // handle of file to read
receiveBuffer, // pointer to buffer that receives data
receiveBytes, // number of bytes to read
&numActual, // pointer to number of bytes read
&osWrite // pointer to structure for data
);
if (!succ)
error = GetLastError();

Eric Hansen

ehansen@pmsi.cc

I have found how to replace the file type combo in the File "Open" dialog with a new one graphically. I want to replace the standard combo box with CComboBoxEx so I can put icons next to the types. But once I do that - how do I communicate to the common dialog when the user selects a new file type? The original file type combo box of the common dialog is still available but invisible. Both combos have the same text. I have tried to programatically set the selection of the original combo to that of the extended combo thinking that that action would cause the appropriate updates but it does not work. Any ideas?

> I have tried to programatically set the selection of the original combo
> to that of the extended combo thinking that that action would cause
> the appropriate updates but it does not work.

I don't think hidden windows send notifications, so you could try changing the selection and the explicitly sending the CBN_SELCHANGE notification to the dialog using the original combo-box's window handle.

UINT nID = ::GetDlgCtrlID ( hOldCombo );
SendMessage ( WM_COMMAND, MAKELPARAM ( nID, CBN_SELCHANGE ), hOldCombo );

Not sure if this will work, since I've never tried it.

-Ben

"Its funny when you stop doing things not because they’re wrong, but because you might get caught." - Unknown

Looks like the reply here is for another topic. Anyone with any ideas for the original question? Confused | :confused:

It looks like the response here is for another thread. Getting back to this now and no luck yet. Any responses still greatly appreciated Smile | :)

I want to record a sound and play a sound in MFC! How will I do that....
Is there any classes that supports multimedia? I know about the MCI.... but I only have code in Win32 Frown | :(

HELP!!

/*
BETA
*/

You may want to check out.. http://www.codeproject.com/audio/fister.asp

Smile | :)

Rob Jones

You may want to check out.. http://www.codeproject.com/audio/fister.asp

Smile | :)

Rob Jones

I want to run one program from my code in two ways; (a) run it and wait until it closes, and (b) run it, and then later on check if it is still running and if so, shut it down.

I use ShellExecute() to run it (successfully), giving me an HINSTANCE.

I was under the impression that MsgWaitForMultipleObjects() would be able to wait until the program had finished, so I used this:

MsgWaitForMultupleObjects(1,(HANDLE *)&hInst, TRUE, INFINITE, 0);

but it doesn't wait, it just goes right on to the next statement. I also tried QS_ALLINPUT originally for the last parameter; no change. I'm not quite sure what that last parameter does exactly.

So, how do I wait for that program to finish? WaitForSingleObject() says it is not advised to use it in case the run program creates other threads (or something like that, it's all too deep for me), which is why I used MsgWait...().

Also, in 16-bit MFC you could call GetModuleUsage() to find out if the hInst was still running... how do I do this in 32-bit MFC? Also, how do I get a handle to the main window of that EXE from that hInst?

Lastly, some functions such as GetModuleFileNameEx() require a module handle AND a process handle... MSDN says a module is an EXE or DLL, so if my hInst is an EXE, how on Earth do I get the process handle it belongs to? Or are they one and the same in this case?

Help! Smile | :)

Use ShellExecuteEX. It takes the address of a SHELLEXECUTEINFO structure as parameter. SHELLEXECUTEINFO has the hProcess member which you can pass to WaitForSingleObject or TerminateProcess.

You can also use CreateProcess instead of ShellExecuteEx.

Tomasz Sowinski -- http://www.shooltz.com.pl

ShellExecuteEx() certainly gave me the process handle - excellent. The problem I am left with now is that this program that I run needs to talk to my app using user-defined messages (through SendMessage() ). If I call WaitForSingleObject(), the second app is stuck. I tried using MsgWaitForMultipleObjects() with the process handle (which now waits as expected) and the final parameter of 0 - but the second app got stuck again. I tried QS_INPUT as the final parameter, which I believe means that my app (the one waiting) should still process any incoming messages as normal while it is waiting for the second app... but it still blocks.

My only theory is that I have to call MsgWait...() from the actual window which will process those messages (it is currently being called from a window embedded in the main window, and not a direct descendant).

Anyone know why I can't get my app to still process messages while waiting for that other app to exit?

> If I call WaitForSingleObject(), the second app is stuck

I'm not sure what do you mean by 'second app' - the one which called ShellExecuteEx, or the child process?

Anyway, I'd move ShellExecuteEx and WaitForSingleObect to a separate thread - this way your message pump will work without any problems. When child process ends and WaitForSingleObject finishes, just call PostMessage to ensure that your main thread (the one with message pump) knows about it.

Tomasz Sowinski -- http://www.shooltz.com.pl

If I have to tell the main thread that the other app ended, doesn't that defeat the whole point of WaitForSingleObject()? I want the code to hang around waiting for this second app (child process) before it continues, with the exception of processing the special messages. Actually, that is another issue - how can it process ONLY non-UI messages? I don't want to allow buttons to be clicked, things to be typed, the app to be closed, etc. I DO want timers to go off, repainting to be done, and my special messages to be processed...

Perhaps I need to disable the main window of my application so the user can't interact, instead of trying to wait? That would still allow my special messages to be processed by the main frame (I think), and would solve this issue. But I still want to know how to do it properly...

Your secondary thread will be in wait state in WaitForSingleObject until child process ends. Threads in wait state use no processor time - the impact on system resources will be minimal. It's the most "economical" way to wait for other process to finish.

Disabling the main window is OK - if you deal with CFrameWnd derivatives, try BeginModalState/EndModalState.

Tomasz Sowinski -- http://www.shooltz.com.pl

I think you've done WaitFor...() in the same thread
as your windows message loop. If you want to do a wait
and still process messages, you'll need to do that wait
in another thread, and then when the wait completes
post a message to your main thread (the one with the
message loop) so that the main thread can do what it
needs to do.

Stephen Kellett
--
C++/Java/Win NT/Unix variants
Memory leaks/corruptions/performance/system problems. UK based.
Problems with RSI/WRULD? Contact me for advice.

I only want special messages and the most basic ones to be let through. I want WM_TIMER and WM_PAINT, and a couple of user defined messages. This is because the spawned process needs to use those special messages to get data from my app. I don't want the user to be able to interact with my program while the spawned process is running.

I was under the impression that MsgWaitForMultipleObjects() could perform a wait while letting messages through, but that seems to do the same as WaitForSingleObject() - it stops message processing.

Any ideas?

Try something along this line:

LPSTR cmdLine;
// set your commandline here

PROCESS_INFORMATION ProcessInfo;
STARTUPINFO StartupInfo = {0};
StartupInfo.cb          = sizeof(STARTUPINFO);

if (::CreateProcess(NULL, cmdLine, NULL, NULL, FALSE,
                    0, NULL, NULL, &StartupInfo, &ProcessInfo))
{
    DWORD dwStatus = STILL_ACTIVE;
    while (dwStatus == STILL_ACTIVE)
    {
        ::GetExitCodeProcess(ProcessInfo.hProcess, &dwStatus);
        Sleep(1000);
    }

    CloseHandle(ProcessInfo.hProcess);
    CloseHandle(ProcessInfo.hThread);

}

You may need/want to use peekMessage and TranslateMessage inside the while loop in order to intercept messages.

Okay, Tomasz said you how get the hProcess...
If you want to Know if the application is still running, you need to use the following.

DWORD dwExitCode;
GetExitCodeProcess(hProcess, &dwExitCode);
If the application is still running dwExitCode returns STILL_ACTIVE

Cheers!!!
Smile | :)

Carlos Antollini.