|
learn C++ and MFC 
|
|
|
|
|
You mean you suggest ,
Effective C++ 5th Edition by Tox!
MFC internals 6th Edition by Great Grand Tox!
?
ROTFL! 
OK,. what country just started work for the day ? The ASP.NET forum is flooded with retarded questions. -Christian Graus
Best wishes to Rexx[^]
|
|
|
|
|
I think what toxcct was saying is that in this specific case, you have to enforce a UNICODE string event if unicode is not defined for the project. AFAIK, the L macro enforces a 16-bits characters string. Thus, if you disable UNICODE, CString will hold 8-bits characters and you are trying to put a 16-bits character string in it, which will not compile properly.
Thus, in this specific case, you have to be sure that the CString is a 16-bits char string, thus the CStringW. Of course, you won't be able to do a lot of things with this string...
|
|
|
|
|
Cedric Moonen wrote: I think what toxcct was saying is that in this specific case, you have to enforce a UNICODE string event if unicode is not defined for the project. AFAIK, the L macro enforces a 16-bits characters string. Thus, if you disable UNICODE, CString will hold 8-bits characters and you are trying to put a 16-bits character string in it, which will not compile properly.
I known that. But that wasn't a lesson for generic text mappings. I just wanted to remove the obstacle from the OP way.
Cedric Moonen wrote: Thus, in this specific case, you have to be sure that the CString is a 16-bits char string, thus the CStringW. Of course, you won't be able to do a lot of things with this string...
That's not true: you can do a lot of things with such a string, provided you rewrite the whole project using (as suggested by toxcct) the W postfix for every API manipulating it. 
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
[My articles]
|
|
|
|
|
Cedric Moonen wrote: I think what toxcct was saying is that in this specific case, you have to enforce a UNICODE string event if unicode is not defined for the project.
Somehow, I have a strong reason to assume that the OP will have UNICODE defined. Because, he is clearly using Unicode and calling upon the "W" versions of each and every API is a real pain if you ask me.
Plus, that kind of code is not terribly good. That's because, if there's a need for an ANSI build sometime later, ... pain.
Of course, the OP needs a tutorial on generic text mappings, but what the heck...
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
don't get me wrong, I always take the road of Generic Text Mappings ( _T() and Co ) but sometimes, you just need a plain ANSI or a plain UNICODE string, regardless the compile mode...
that's what the OP wants here... he wants the 'Omega' symbol, even though he is building ANSI or not.
|
|
|
|
|
toxcct wrote: MessageBoxW(str);
CPallini is not wrong, you are. When UNICODE is defined, the compiler does this for you automatically. I don't see a need to call the "W" versions of the APIs explicitly.
I know the OP is possibly using only Unicode here. Usually, I would rather prefer to go with Generic Text Mappings: CString str(_T("\x03A9"));
With this, if we do an ANSI build sometime later, we don't have to change an an awful lot of things.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Rajesh R Subramanian wrote: I don't see a need to call the "W" versions of the APIs explicitly.
look closer bro, here, CPallini is not using _T(), he is directly creating a wide string using L""...
so as long the string literal is wide, the object that stores it will have to be wide too.
so why making things unclear and depend on a compilation mode rather than telling explicitely that we are using what the compiler would have chosen (if UNICODE defined) or failed (if ANSI)...???
|
|
|
|
|
toxcct wrote: look closer bro, here, CPallini is not using _T(), he is directly creating a wide string using L""...
I agree, that will require the OP to read a good tutorial on Generic Text Mappings.
The point what I wanted to make was that if we go around calling the "W" versions of APIs everywhere, then building an ANSI version will be an unnecessarily complicated task. Neither do I encourage using L"", but calling the Wide versions of APIs are even bad.
Plus, there's a strong reason for CPallini to assume that the OP has UNICODE defined, because he's clearly using Unicode!
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Using CStringW just here doesn't mean to use it everywhere in the code.
moreover, it is obvious the OP wants a UNICODE Character (Omega). so, no, don't make the code obscure. even though the compiler is set UNICODE or ANSI, it doesn't forbid you to write a clear (but not against performance anyway) code and show what you're actually doing here : getting a Wide character.
Note also that CStringW is somewhat useless for a single character. a WCHAR could have been used too here... and regardless we know or not if the OP has UNICODE defined !
|
|
|
|
|
toxcct wrote: a WCHAR could have been used too here
Yes and then what do you suggest, passing the WCHAR to the MessageBoxW function?
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
[My articles]
|
|
|
|
|
Hi all,
I want to write some data into a DB using ADO. I got an error for the following code.
"Multiple-step operation generated errors. Check each status value."
Here is the code.
<br />
m_pRecSet->AddNew();<br />
<br />
vtData.vt = VT_INT;<br />
vtData.intVal = static_cast<int>(23);<br />
m_pRecSet->Fields->GetItem("PackID")->PutValue(vtData);<br />
<br />
m_pRecSet->Update();<br />
Can someone tell me what that error means?
I appreciate your help all the time...
CodingLover
|
|
|
|
|
CodingLover wrote: Can someone tell me what that error means?
Which statement generates the error?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Check if you are using transactions among the context
|
|
|
|
|
Hi,
In Visual studio 2005, when I use AfxGetInstanceHandle function directly or via calling another function such as CWnd::CreateEx inside an MFC extension dll, an assertion is thrown.
This is despite the fact that the same codes used to work fine in prior versions of visual studio.
What should be done to resolve this problem?
Thanks
|
|
|
|
|
Some questions:
1.) Are you expecting to recieve the base address of the DLL or the process executable?
2.) Is the extension DLL initialized properly? AfxInitExtensionModule[^]
3.) Whats the assertion?
Hack alert:
Replacing the call to AfxGetInstanceHandle with the following code might prevent the assertion... but HIDE the root cause of the it. 
(HINSTANCE)&__ImageBase
Why it works:
AfxGetInstanceHandle[^] simply returns the base address of the DLL and __ImageBase is the intrinsic equivalent.
Here is another hacked-up way to get the instance handle:
__inline HINSTANCE MyGetInstanceHandle(LPCTSTR lpModuleName)
{
HINSTANCE h;
GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS, lpModuleName, &h);
return h;
}
Don't use the code I have provided to bypass the assertion, it sounds to me like MFC has not been properly initialized.
Best Wishes,
-David Delaune
|
|
|
|
|
First of all answers to above questions:
1) Refering to Memory Management section of Extension DLLs in MSDN:
MFCx0.dll and all extension DLLs loaded into a client application's address space use the same memory allocator, resource loading, and other MFC global states as if they were in the same application. This is significant because the non-MFC DLL libraries and the regular DLLs do the exact opposite and have each DLL allocating out of its own memory pool.
If an extension DLL allocates memory, that memory can freely intermix with any other application-allocated object. Also, if an application that dynamically links to MFC fails, the protection of the operating system maintains the integrity of any other MFC application sharing the DLL.
Similarly other global MFC states, like the current executable file to load resources from, are also shared between the client application and all MFC extension DLLs as well as MFCx0.dll itself.
So I expect to receive the address space of process executable.
I checked hInstance value in DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved), it was 0x10000000 but it was not equal to the value returned by AfxGetInstanceHandle in process executable which was 0x00400000, despite the fact that they should have been the same!
2) Yes it's been properly initialized using AfxInitExtensionModule in its DllMain
3) AfxGetInstanceHandle asserts in its ASSERT(afxCurrentInstanceHandle != NULL); line
And I cannot use the code that you've mentioned because AfxGetInstanceHandle is also called from functions within MFC that I have no control on such as CWnd::CreateEx that cause the assertion again.
I really have no idea why MFC might have not been properly initialized! 
Thank you for your feedback
|
|
|
|
|
Neptune,
There is a sample MFC Extension DLL provided by Microsoft. Perhaps you should take a look at the source code and compare it to your project.
DLLHUSK MFC Extension DLL[^]
Best Wishes,
-David Delaune
|
|
|
|
|
Hi,
In visual studio 2005, I opened the dllhusk sample, it simply didn't work, I could neither open its properties nor run it!
Anyway, I've been so busy on other projects since then, thus I couldn't spend time on this one, though my mind was always busy with this problem.
Today while I was doing some tests on another project I found the reason for that assert:
In project properties:
"Configuration Properties->General->Character Set" should be set to "Use Multi-Byte Character Set" instead of "Use Unicode Character Set".
The interesting point is that visual studio sets this setting to "Use Unicode Character Set" by default causing these kind of issues to those who migrate their code from previous versions of visual studio without making any hint or warning.
Thank you again david for your feedbacks
|
|
|
|
|
Hello,
I developed an application for my client using VC++ 2005 (unmanaged) that monitors equipment at different remote sites. It communicates with the equipment through Leased Line or Dial-up modem. In my case, same modem is working as leased line and dial-up modem. The application is working fine when leased line is used, but with dial-up connection, sometimes it shows timeout. My client has a similar Win16 application which is working fine with same phone line, modem and equipment.
The equipment uses ACK/NAK for successful/unsuccessful data communication.
I am using a small speed of 2400 baud, opened for overlapped operation, "ReadIntervalTimeout" value is set to 1 and all the other timeout values are set to 0.
My port reader function is reading 1 byte at a time, and it is working fine for all other cases except for the dial-up modem. Is this the problem for timeout?
I have captured the data at timeout and analyzed the data byte by byte, found that port reader function is reading invalid data. Suppose, a valid data stream is 32 bytes in length, the reader function is reading all 32 bytes, failed to read last few byte(s) in time, but end up with a complete data stream of perfect length of 32.
Say, this is a valid data:
10 02 1c 00 43 4d 54 00 00 00 00 00 00 00 31 00
00 00 00 00 00 00 01 00 62 00 65 07 74 49 8a a1
But when timeout occurs, this data is getting read like this
10 02 1c 00 43 4d 54 00 00 00 00 00 00 00 31 00
00 00 00 00 00 00 00 01 00 62 00 65 07 74 49 8a
The last byte "a1" is read later but before that my function send the previous data for CRC check that will obviously failed. This thing is happening for large data stream.
Someone please tell me how I can handle this TIMEOUT problem.
Thanks in advance.
|
|
|
|
|
I've never used a modem, just a port for serial comms but have seen similar problems.
First I'd recommend if you are not using PortMon or a similar utility to do so to see exectly whats happening at a lower level.
Obviously you could extend the timeout but whilst 2mS might work, there's still (presumably) nothing in your code to handle what to do if it doesn't.
Why read a byte at a time? OK it works, but you could attempt to read the number of bytes expected in the whole expected message and then check the number of bytes read? You could then get, say 28 bytes when you expect 30, buffer them read again and add the first 2 bytes of the second read to the end of the buffer etc.
When using ports I work on the assumption that you may not get what you expect:
while(!bFullMessageReceived)
{
BOOL bRead = ::ReadFile(m_portHandle, static_cast<LPVOID>(ReadBuff), dwMaxBytesToRead,&dwBytesRead,NULL);
if(FALSE == bRead)
{
...
I would recommend treating a timeout as something that is a valid event, which it is. It's not an error: it happens and it not in your control, so you have to deal with it.
|
|
|
|
|
Thanks for your response.
As a matter of fact, I tried in all the ways I could think of to avoid that timeout. Now I realized why it did not work for me.
So, I think that my program is not sending NAK to the equipment properly. By the way, I am using "WriteFile" to send single character of NAK (21), is it correct to use this function to send a single character or should I use "TransmitCommChar"?
Thanks again.
|
|
|
|
|
Hi,
You are probably right about the NAK error, there will be some underlying cause for your time-out and this may be it.
I have seen this in code I recently looked at: No sending of ACK (or NAK). Also no dealing with an error-code which is being returned for some reason when the code expected an ACK.
Until you mentioned TransmitCommChar I didn't know about it (so thanks) but it does sound OK to use as it takes priority over any other characters in the output buffer. Conversly, the only one who will place characters in the output buffer is yourself - so if you know you haven't put any there WriteFile will work OK as well.
Jonathan
|
|
|
|
|
My friend "Create window in Work thread" when she need a message pump (message loop? I am not sure, sorry I am a beginner).
She just create a window, and then do a loop like WndProc does.
 I am also worry about if it could work
I know that MFC has a UI thread that with a message Pump can do this without creating a window. But I cannot persuade she to use UI thread instead of a "Work thread with window", because of my pity knowledge .
could any one help me about that.
|
|
|
|
|
The only difference between a UI thread and a worker thread is that a UI thread has a message loop.
So what your friend has created is a UI thread rather than a worker thread.
«_Superman_»
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
