C / C++ / MFC

COM PORT Does NOT receives all Data!

27-Jul-05 5:44

I suspected that but you did not indicate it was a problem so I pursued other possibilities.

Halawlaws wrote:
...sorry for wasting your time

If the net result is that you learned something, how has time been wasted?

"One must learn from the bite of the fire to leave it alone." - Native American Proverb

tomek1827-Jul-05 4:21

tomek18

27-Jul-05 4:21

Hi...

My program is recieving data at 9600bytes (with standard settings), in chunks. 40 or more characters at a time. When the Data is displayed straight away on the screen, everything is cool.
But when I do simple calculations, it misses a lot of characters, and from 40 I might only recieve 20! and some characters turn to little squares.

I have tried reducing the amount of Data transfered to 5 characters, but even so it misses a few, without any pattern.

Is it possible to build a buffer quick enough to store all the 40 characters, then do the calculations of them.

Please give me some suggestions...

Here's part of my code.

void CChildView::SortData(LPCTSTR pszData)<br />
{<br />
<br />
	//copies pszData into buffer<br />
	TCHAR buffer[10];<br />
	_tcsncpy(buffer, pszData, 10);<br />
	<br />
	//converts UniCodeString to ASCII returns buffer<br />
	char AsciiStr[10];<br />
	WideCharToMultiByte (CP_ACP, 0, buffer, -1, AsciiStr, 10, NULL, NULL);<br />
<br />
	//testing, loop increments AsciiBuffer by 1 and stores AsciiStr in AsciiBuffer<br />
	static char AsciiBuffer[11] = "          ";<br />
	static int nPass=0;	<br />
<br />
	AsciiBuffer[nPass++] = AsciiStr[0];<br />
	<br />
	// when 10 characters are collected <br />
	if (nPass == 10)<br />
	{			<br />
	// saves data to a file, add's to exciting contents.<br />
		ofstream testFile( "test.txt", ios::app );<br />
			testFile << AsciiBuffer << " ";<br />
		testFile.close();<br />
		nPass =0;<br />
	}	<br />
	<br />
	//Displays Data in Window<br />
	DisplayData(pszData);<br />
}//end SortData

Maybe I should store the characters 1st, then convert into Ascii, But how do I convert an Array of Unicode into Ascii?

Thanks heaps!!!

Re: COM PORT Does NOT receives all Data!

Marc Soleda27-Jul-05 5:27

Marc Soleda

27-Jul-05 5:27

it'd be a good thing to make a separate thread dedicated to receive data and putting it into a buffer an another (or the main thread) taking this buffer and treat it.

Marc Soleda.

... she said you are the perfect stranger she said baby let's keep it like this... Tunnel of Love, Dire Straits.

general mfc question: lpszTemplateName

23_44427-Jul-05 4:17

27-Jul-05 4:17

When creating a dialog you have the option of two constructors

CDialog( LPCTSTR lpszTemplateName, CWnd* pParentWnd = NULL );

CDialog( UINT nIDTemplate, CWnd* pParentWnd = NULL );

All the examples I have ever seen use the latter (UINT nIDTemplate). Just for my own edification
could someone tell me how to use the first constructor. I've never seen an example of this. Where do you find the TemplateName? These must be templates created in your code?

The first constructor parameter LPCTSTR lpszTemplateName appears in quite a few constructors, for example:

CFormView( LPCTSTR lpszTemplateName );

CDialogBar::Create
BOOL Create( CWnd* pParentWnd, LPCTSTR lpszTemplateName, UINT nStyle, UINT nID );

CDialog::Create
BOOL Create( LPCTSTR lpszTemplateName, CWnd* pParentWnd = NULL );

CPropertyPage( LPCTSTR lpszTemplateName, UINT nIDCaption = 0 );
COleDBRecordView( LPCTSTR lpszTemplateName );
CRecordView( LPCSTR lpszTemplateName );

David Crow27-Jul-05 5:05

27-Jul-05 5:05

mx483 wrote:
Just for my own edification
could someone tell me how to use the first constructor. I've never seen an example of this. Where do you find the TemplateName? These must be templates created in your code?

In your dialog's constructor, change the first parameter being sent to CDialog's constructor from IDD to MAKEINTRESOURCE(IDD_DIALOG_TEMPLATE) instead.

* Note that IDD_DIALOG_TEMPLATE is whatever name you have in the dialog's class declaration.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

23_44427-Jul-05 5:17

27-Jul-05 5:17

Hey thanks David,

I have seen the MAKEINTRESOURCE macro before. It seems kind of redundant doesn't it. Why bother converting to an INT when you could just use the other constructor.

Could you give an example of the IDD_DIALOG_TEMPLATE name? You said it is whatever name you have in the dialog's class declaration.

I'm still scratching my head. Please provide a snippet. Thanks again for the response. Jay

David Crow27-Jul-05 5:31

27-Jul-05 5:31

mx483 wrote:
Why bother converting to an INT

That macro converts to a string not an int.

mx483 wrote:
Could you give an example of the IDD_DIALOG_TEMPLATE name? You said it is whatever name you have in the dialog's class declaration.

Just look in your dialog's .h file for the value assigned to IDD.

mx483 wrote:
Please provide a snippet.

Did you modify the dialog's constructor like I described?

"One must learn from the bite of the fire to leave it alone." - Native American Proverb

23_44427-Jul-05 6:00

27-Jul-05 6:00

Thanks David,

Be patient, this is coming to me.

I did mispeak on MAKEINTRESOURCE macro. It does indeed return a string.

Here is my call as it was
pDlg->Create(IDD_DIALOG1, this);

Here was my constructor
CDialogView::CDialogView(CWnd* pParent /*=NULL*/)
: CDialog(CDialogView::IDD, pParent)
{
//{{AFX_DATA_INIT(CDialogView)
// NOTE: the ClassWizard will add member initialization here
//}}AFX_DATA_INIT
}

From CFileDialog.h file
// Dialog Data
//{{AFX_DATA(CDialogView)
enum { IDD = IDD_DIALOG1 };
// NOTE: the ClassWizard will add data members here
//}}AFX_DATA

Are you saying I need to modify the constructor of my dialog?

Here is what I did for the new constructor

CDialogView::CDialogView(CWnd* pParent /*=NULL*/)
: CDialog(MAKEINTRESOURCE(CDialogView::IDD), pParent)
{
//{{AFX_DATA_INIT(CDialogView)
// NOTE: the ClassWizard will add member initialization here
//}}AFX_DATA_INIT
}}

Now for the call
pDlg->Create("IDD_DIALOG1", this);

I still get an assert. I'm not sure if this is what you meant.

Thanks, Jay

David Crow27-Jul-05 6:09

27-Jul-05 6:09

mx483 wrote:
: CDialog(MAKEINTRESOURCE(CDialogView::IDD), pParent)

Should be:

: CDialog(MAKEINTRESOURCE(IDD_DIALOG1), pParent)

"One must learn from the bite of the fire to leave it alone." - Native American Proverb

23_44427-Jul-05 6:30

27-Jul-05 6:30

Thanks David,

I think I'm making it more difficult and I think you've answered my question

CDialog one("IDD_DIALOG1", this);
CDialog two(IDD_DIALOG1, this);

Both of these work. So the answer is the template resource name is just the string representation of the ID.

If I derive a class from CDialog, I have to make sure that my constructor in the derived class would accomodate the string using the MAKEINTRESOURCE macro.

How did I do?

Thanks again. I learned something.

David Crow27-Jul-05 7:03

27-Jul-05 7:03

mx483 wrote:
If I derive a class from CDialog, I have to make sure that my constructor in the derived class would accomodate the string using the MAKEINTRESOURCE macro.

How did I do?

What is it that you are wanting to do that a CDialog-derived class does not already do? I must say that in 12+ years of using MFC, I've never used CDialog's constructor that takes a string. Maybe you have an example that shows its usefullness.

"One must learn from the bite of the fire to leave it alone." - Native American Proverb

23_44427-Jul-05 7:32

27-Jul-05 7:32

Nope, I haven't seen one either. Just took the opportunity to learn something new. Thanks again. Jay

Gary R. Wheeler27-Jul-05 12:48

Gary R. Wheeler

27-Jul-05 12:48

Compiled resources may be identified numerically (this is the usual case) or with a string. For example, you could have the following in your .RC file:

IDD_DLG1 DIALOG 0, 0, 210, 150
...
"DIALOG2" DIALOG 0, 0, 200, 200
...

In the first case, you have a #define in your resource.h file for the value IDD_DLG1.

In the second case, you would use the lpszTemplateName form of the constructor, passing the string "DIALOG2".

The MAKEINTRESOURCE macro converts an integer resource identifier to a form that the resource loading logic recognizes, returning it as a string type.

Software Zen: delete this;

23_44428-Jul-05 2:46

Serial Comms with 9-bit data

28-Jul-05 2:46

Perfect! Thanks a bunch. It was a conceptual question. I have no reason to use a string but thought I should at least understand the concept. Thank you.

button_basher27-Jul-05 4:01

button_basher

27-Jul-05 4:01

Howdy folks

Having a problem getting my COM port to talk to a piece of hardware using a 9-bit data protocol. I am using Visual Studio .NET 2003 and developing in C++ using the standard Win32 serial communications techniques. Specifically I have:

- Used CreateFile to get a Handle on my COM port
- Created a DCB structure to send 8-bit with PARITY bit making up the ninth bit
- Bytes are then sent to the hardware using WriteFile

When I wish to send a byte with the ninth bit as '1' I call GetCommState change the DCB to have MARK Parity then SetCommState to reinitialise the COM Port. Likewise to send a byte with the ninth bit as '0' I call GetCommState change the DCB to have SPACE Parity then SetCommState to reinitialise the COM Port.

This all works fine and my COM port talks to the hardware as required.

My problem is that it is very slow. Each time GetCommState & SetCommState are used to change the DCB parity it takes about 10ms. At the baud rates I am using a byte only takes 50us to transmit so this delay to switch parity makes a big difference.

Does anyone have an idea to speed up the parity change or a better method of obtaining a ninth bit.

Many Thanks

b_b

Re: Serial Comms with 9-bit data

JWood27-Jul-05 9:30

JWood

27-Jul-05 9:30

That 9-bit is definitely non-standard, so it might take some more detailed alteration of the structure. You might have to look closely at that DCB structure, to make sure that the specified protocol supports it. From what you have said, it sounds like it is sending back a nawk repeatedly or some other error code and then retransmitting until some timeout occurs. Change the timeout to a lower value to see if this speeds it up. This is not the solution - just confirmation of this theory.

Re: Serial Comms with 9-bit data

button_basher28-Jul-05 2:16

button_basher

28-Jul-05 2:16

Hello

I don't think I agree.

Really all I am doing is sending 8-bit data with a Parity bit and one Stop bit. The parity bit just happens to be being used as data bit 8 by the recieving hardware.

Using a serial port monitor to look at behaviour of the COM port the delay seems to happen when SetCommState() is executing. There are no error codes being output. It is simply reinitialising the COM port albeit slowly.

Thanks for your response

b_b

The message when the dialog is covered

jerome_data27-Jul-05 3:40

jerome_data

27-Jul-05 3:40

I Search the message when a dialog is covered by other windows.
I want to close the dialog when the user hide this with the mouse when he selects a other application for example.

Thanks

Re: The message when the dialog is covered

David Crow27-Jul-05 4:03

Re: The message when the dialog is covered

27-Jul-05 4:03

Check out the WM_ACTIVATE and WM_ACTIVATEAPP messages.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

jerome_data27-Jul-05 4:47

jerome_data

27-Jul-05 4:47

THANKS

void CDialog::OnActivate( UINT nState, CWnd* pWndOther, BOOL bMinimized )
{
if(nState==WA_INACTIVE)
{
CDialog::OnOK();
}
CDialog::OnActivate(nState, pWndOther, bMinimized);
}

how to monitor the printer?

szcococut27-Jul-05 3:11

szcococut

27-Jul-05 3:11

if a file is printed,I can monitor the file ,include
the file's path,the file size ,the file's content.
thanks!

Re: how to monitor the printer?

David Crow27-Jul-05 3:14