|
If you configure a COM for synchronous operations (see for instance [^]) then each call to ReadFile becomes a blocking one (until timeout expires, see [^]).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks for the info, but to go back to my original problem: Does this solve it, or is it a better way to communicate for me with the com port?
|
|
|
|
|
At least, you can try.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
OK I deserved that one, ofcourse I can try, and I will..
|
|
|
|
|
Okay, I've tried the synchrounous approach but there is no change in the situation.
|
|
|
|
|
FPeeters wrote: I configure a connection between my app and the COM1 port of a PC using the following piece of code:
hComm = CreateFile(("COM1"),
Shouldn't this be:
CreateFile("\\\\.\\COM1", ...);
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Both methods are correct. You could consider "COM1" as a mapping to "\\\\.\\COM1" such as is created by DefineDosDevice[^]
Best Wishes,
-David Delaune
|
|
|
|
|
DavidCrow wrote: Shouldn't this be:
CreateFile("\\\\.\\COM1", ...);
This is, sadly enough, not the solution to my problem. But I'm curious: what is the meaning of "\\\\.\\"
|
|
|
|
|
FPeeters wrote: But I'm curious: what is the meaning of "\\\\.\\"
It's just a format that some arguments to CreateFile() must have. COM1 must not be one of those. Sorry 'bout that.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
It is the UNC [^] path of COM1 .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Hello Frank,
You should paste the contents of your DCB structure so I can take a look at it. There are some combinations of values that do not work. If you are also setting the COMMTIMEOUTS structure please paste that here as well.
Best Wishes,
-David Delaune
|
|
|
|
|
DCB structure:
DCBLength = 28
BaudRate = 38400
fBinary = 1
fParity = 0
fOutxCtsFlow = 0
fOutxDsrFlow = 0
fDtrControl = 1
fDsrSensitivity = 0
fTXContinueOnXoff = 1
fOutX = 0
fInX = 0
fErrorChar = 0
fNull = 0
fRtsControl = 1
fAbortOnError =1
fDummy2 = 0 (this one is not used but added for the complete structure)
wReserved = 0 (this one is not used but added for the complete structure)
XonLim = 2048
XoffLim = 512
ByteSize = 7
Parity = 0
StopBits = 0
XonChar = 17
XoffChar = 19
ErrorChar = 0
EvtChar = 0
wReserved1 = 0 (this one is not used but added for the complete structure)
The current settings for the Barcode reader are:
BaudRate = 38400 (default value)
DataBits = 7
Parity = NONE
StopBits = 1
RTS/CTS HardwareFlowcontrol = Off
Xon/Xoff SoftWareFlowControl = Off
Ack/Nak SoftwareFlowControl = Off
As for the COMMTIMEOUTS structure: I don't know if I am using this structure. I defined a constant (#define READ_TIMEOUT 5000) and use that in "WaitForSingleObject"
I hope you can send my in the right direction on solving this problem. Please explain any recommended changes in these settings so I can learn from it and avoid this in the future.
|
|
|
|
|
Sorry for the delay, I was not in the office yesterday.
You have some things wrong in your DCB structure.
FPeeters wrote: The current settings for the Barcode reader are:
HardwareFlowcontrol should be off according to your statement on the bottom.
You should make the following changes:
if(TRUE == GetCommState(m_hComm, &m_dcb))
{
m_dcb.BaudRate = CBR_38400;
m_dcb.Parity = NOPARITY;
m_dcb.StopBits = ONESTOPBIT;
m_dcb.fDtrControl = DTR_CONTROL_DISABLE;
m_dcb.fRtsControl = RTS_CONTROL_DISABLE;
m_dcb.fOutxCtsFlow = FALSE;
m_dcb.fOutxDsrFlow = FALSE;
m_dcb.fOutX = FALSE;
m_dcb.fInX = FALSE;
m_dcb.ByteSize = 7;
if(FALSE == SetCommState(m_hComm, &m_dcb))
{
TRACE0(_T("FAILED.\n"));
}
}
I am almost positive that you should change FILE_FLAG_OVERLAPPED to NULL when you open the COM port. I highly doubt that you need to do overlapped I/O with a barcode reader. Don't worry about the COMMTIMEOUTS for now, I was asking this question with the assumption that you were possibly performing overlapped i/o and the timeout structure would effect this.
Here is a good MSDN containing the explanation for the DCB fields. It looks like you just need to match what the barcode scanner is expecting.
http://msdn2.microsoft.com/en-us/library/aa363214(VS.85).aspx[^]
Best Wishes,
-David Delaune
|
|
|
|
|
No problem with the delay, by opening and closing the connection with hyperterminal I can solve the problem for a while (until I shutdown or reboot my computer) so it not stopping me in the development of the app.
I've tested our proposed settings of the DCB structure, but unfortunatly it doesn't solve the problem.
if (!GetCommState(hComm, &dcb))<br />
{<br />
sprintf(str,"GET_COMM_STATE FAILED");<br />
::MessageBox(0,str,"FOUT",MB_OK);<br />
}<br />
else<br />
{<br />
dcb.BaudRate = CBR_38400;<br />
dcb.Parity = NOPARITY;<br />
dcb.StopBits = ONESTOPBIT;<br />
dcb.fDtrControl = DTR_CONTROL_DISABLE;<br />
dcb.fRtsControl = RTS_CONTROL_DISABLE;<br />
dcb.fOutxCtsFlow = false;<br />
dcb.fOutxDsrFlow = false;<br />
dcb.fOutX = false;<br />
dcb.fInX = false;<br />
dcb.ByteSize = 7;<br />
<br />
if (!SetCommState(hComm, &dcb))<br />
{<br />
sprintf(str,"SETCOMMSTATE ERROR");<br />
::MessageBox(0,str,"FOUT",MB_OK);<br />
}<br />
else<br />
{<br />
}
I've found the suggested MSDN already, but thanks for the suggestion.
Is there a possibility to check the settings of the HyperTerminal programm in a DCB-structure, so I can see what settings this programm uses and copy them?
Or when I start Hyperterminal and close it again and then use the GetCommState command, do I get the settings Hyperterminal used?
Maybe HyperTerminal sends some activating code to any connected device?
Frank Peeters.
|
|
|
|
|
Hi,
I have a application that allow to run multiple instances. If at same time two instances are runnining and I want to close one with another exe throgh ProcessTreminate() command then how can I differentiate these two instances which is to be close.
|
|
|
|
|
pther wrote: If at same time two instances are runnining and I want to close one with another exe throgh ProcessTreminate() command
Why don't you instead restrict the number of instances of your application to just one?
Here's a reference link: Avoiding multiple instances[^]
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
pther wrote: how can I differentiate these two instances
you may need to enumerate the processes(EnumProcesses) and find whether the process is created by same executable file (GetModuleBaseName) and the process ID differentiates the multiple instance.
|
|
|
|
|
Hey man. Please don't tell him all that. He's trying to do something bizarre. IMHO, he must be restricting his application to one instance.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
I thought he wants to terminate the process which is not under his control (which is not programmed by him).
|
|
|
|
|
You are correct that took me correct. Actually problem is this I have a exe that behaves in 2 ways:
If run by user it is getting maximized, if run by timer(automatically) then it is in minimize mode. I want to close the minimize application as soon as it completes its job.
Task manager shows the same process name 2 times then how can I recognise which process in minimized.
|
|
|
|
|
pther wrote: how can I recognise which process in minimized.
See GetWindowPlacement[^]
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Yes this may work but through another exe I can get the HANDLE of process
like :
HANDLE hProcess = OpenProcess( PROCESS_QUERY_INFORMATION |PROCESS_VM_READ,FALSE, processID );
How can I pass this HANDLE to :
GetWindowPlacement(HWND hWnd,WINDOWPLACEMENT *lpwndpl);
|
|
|
|
|
pther wrote: if run by timer(automatically) then it is in minimize mode
what makes the application to go into minimised mode. How you are spawning the application.
pther wrote: I want to close the minimize application as soon as it completes its job.
TerminateProcess API won't ensure that the job has completed.
I would say killing a process is cruel programming.
If this application is developed youself see Rajesh's reply[^] to restrict the number of instance. Why you need to kill the minimised one.
|
|
|
|
|
Rajkumar R wrote: Why you need to kill the minimised one.
I think he's trying to develop a 'killer app'.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
pther wrote: If run by user it is getting maximized, if run by timer(automatically) then it is in minimize mode. I want to close the minimize application as soon as it completes its job.
So what's the problem?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|