|
no for the 1st question and yes
/\|-||\/|/\|)
|
|
|
|
|
What you have should work. Given that it does not, something else is amuck with your machine. This is just a grasp but what if you replace the first parameter with a real window handle instead of NULL? This way if the browser needs to report an error, it can.
Windows Explorer might be compensating for something that is missing. Use FindExecutable() to retrieve the name of the .exe that is associated with the .htm file.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Don't worry it worked apparently it turned out that the file path was correct but the file name of my file is index.html and not index.htm.
Thanks for ur help in debugging and sorry for wasting your time
ciao
/\|-||\/|/\|)
|
|
|
|
|
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
|
|
|
|
|
 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 />
TCHAR buffer[10];<br />
_tcsncpy(buffer, pszData, 10);<br />
<br />
char AsciiStr[10];<br />
WideCharToMultiByte (CP_ACP, 0, buffer, -1, AsciiStr, 10, NULL, NULL);<br />
<br />
static char AsciiBuffer[11] = " ";<br />
static int nPass=0; <br />
<br />
AsciiBuffer[nPass++] = AsciiStr[0];<br />
<br />
if (nPass == 10)<br />
{ <br />
ofstream testFile( "test.txt", ios::app );<br />
testFile << AsciiBuffer << " ";<br />
testFile.close();<br />
nPass =0;<br />
} <br />
<br />
DisplayData(pszData);<br />
}
Maybe I should store the characters 1st, then convert into Ascii, But how do I convert an Array of Unicode into Ascii?
Thanks heaps!!!
|
|
|
|
|
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.
|
|
|
|
|
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 );
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Nope, I haven't seen one either. Just took the opportunity to learn something new. Thanks again. Jay
|
|
|
|
|
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;
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Check out the WM_ACTIVATE and WM_ACTIVATEAPP messages.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
THANKS
void CDialog::OnActivate( UINT nState, CWnd* pWndOther, BOOL bMinimized )
{
if(nState==WA_INACTIVE)
{
CDialog::OnOK();
}
CDialog::OnActivate(nState, pWndOther, bMinimized);
}
|
|
|
|
|
if a file is printed,I can monitor the file ,include
the file's path,the file size ,the file's content.
thanks!
|
|
|
|
|
szcococut wrote:
if a file is printed,I can monitor the file ,include
the file's path,the file size ,the file's content.
Ok, now that you've told us what you can do, what is it that you want to do? Do any of these help?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
