|
Talk about living a tough life then.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
Are you able to type in Chinese character into the control without password style at first? The app is fully Unicode?
I am able to type Chinese character into a CEdit control with and without password style. There's something else wrong I guess.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
Rajesh R Subramanian wrote: I am able to type Chinese character into a CEdit control with and without password style.
Just curious: what are you entering?
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]
|
|
|
|
|
CPallini wrote: Just curious: what are you entering?
I don't know, but I pressed some random keys and this character[^] appeared. I may not be able to reproduce the thing though.
I promise never to set a Chinese password. No, really.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
Rajesh R Subramanian wrote: I don't know, but I pressed some random keys and this character[^] appeared
That's wonderful, let's play Mahjong!
BTW
Rajesh R Subramanian wrote: Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
Here the goal is Hijacking, of course.
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]
|
|
|
|
|
Hehe...
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
Hi all,
I have a project that uses unicode character set this snippet gives me an error:
CMimeMessage msg;
CoInitialize(0);
msg.SetSender(L"Administrator@redmap.com");
msg.SetSenderName(A2T("Redmap Networks"));
msg.AddRecipient(EmailAddress);
strValue = W2A(EmailAddress);
char dom[100]="";
int a = GetDomain(strValue.c_str(), dom);
if (a == 0){
strValue = dom;
msg.SetSubject(A2T("Download Notification"));
The bold part gives me errors and i found them here(atlmime.h):
inline BOOL SetSenderName(LPCTSTR szName, UINT uiCodePage = 0) throw()
{
if (szName == NULL)
return FALSE;
CHeapPtr<char> szNamePtr;
UINT nLen(0);
BOOL bRet = AtlMimeConvertString(m_spMultiLanguage, uiCodePage, szName, &szNamePtr, &nLen); if (bRet)
{
It seems that m_spMultiLanguage must be initialized, how do I do that?
I tried calling CoInitialize(0) before feeling up msg it wont work. Any advice?
Thanks,
Jayjay
|
|
|
|
|
What error did you get?
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]
|
|
|
|
|
Its all ok now i just had to call coinitialize before creating an object.
|
|
|
|
|
I am in the process of reading the Book "Windows 95 with MFC" by Jeff Prosise. I am using the first edition of the book. I have compiled the program Paint4 which is the first example given of
the Document/View Architecture. I have copied the code directly from the CD. With two very minor
changes, the code compiles but fails to run. I am wondering, if this example is known to be bad. I looked around on the internet for a list of know errors in this book. However, I could not find such a list. I would like to get this example running, however, I am finding it hard to debug. The program bombs out inside MFC code.
Any advice?
Thanks
Bob
|
|
|
|
|
BobInNJ wrote: Any advice?
Does the program fail to start, or does it start and then stop before any window is drawn? How about setting a breakpoint in the app's InitInstance() to find out?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
BobInNJ wrote: I would like to get this example running, however, I am finding it hard to debug.
Maybe we could help with that, however you should be more detailed about the runtime error.
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]
|
|
|
|
|
Thanks for the responses. Here are the details on the error: It dies with an assertion
error in the following MFC module:
void CSingleDocTemplate::SetDefaultTitle(CDocument* pDocument)
{
CString strDocName;
if (!GetDocString(strDocName, CDocTemplate::docName) ||
strDocName.IsEmpty())
{
// use generic 'untitled'
ENSURE(strDocName.LoadString(AFX_IDS_UNTITLED));
}
pDocument->SetTitle(strDocName);
}
Here is my InitInstance method.
BOOL CPaintApp::InitInstance ()
{
SetRegistryKey (TEXT("Programming Windows 95 with MFC"));
LoadStdProfileSettings ();
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate (
IDR_MAINFRAME,
RUNTIME_CLASS (CPaintDoc),
RUNTIME_CLASS (CMainFrame),
RUNTIME_CLASS (CPaintView)
);
AddDocTemplate (pDocTemplate);
RegisterShellFileTypes (TRUE);
CCommandLineInfo cmdInfo;
ParseCommandLine (cmdInfo);
if (!ProcessShellCommand (cmdInfo))
return FALSE;
m_pMainWnd->DragAcceptFiles ();
return TRUE;
}
The code reaches the call to ProcessShellCommand. However, it dies in that call. Here is the call stack when it dies.
> chap8.1.exe!CSingleDocTemplate::SetDefaultTitle(CDocument * pDocument=0x003d9610) Line 210 + 0x2b bytes C++
chap8.1.exe!CSingleDocTemplate::OpenDocumentFile(const wchar_t * lpszPathName=0x00000000, int bMakeVisible=1) Line 141 C++
chap8.1.exe!CDocManager::OnFileNew() Line 848 C++
chap8.1.exe!CWinApp::OnFileNew() Line 22 C++
chap8.1.exe!_AfxDispatchCmdMsg(CCmdTarget * pTarget=0x0065eaf8, unsigned int nID=57600, int nCode=0, void (void)* pfn=0x004afaee, void * pExtra=0x00000000, unsigned int nSig=57, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 82 C++
chap8.1.exe!CCmdTarget::OnCmdMsg(unsigned int nID=57600, int nCode=0, void * pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 381 + 0x27 bytes C++
chap8.1.exe!CWinApp::ProcessShellCommand(CCommandLineInfo & rCmdInfo={...}) Line 24 + 0x20 bytes C++
chap8.1.exe!CPaintApp::InitInstance() Line 43 + 0xc bytes C++
chap8.1.exe!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x00020928, int nCmdShow=1) Line 37 + 0xd bytes C++
chap8.1.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x00020928, int nCmdShow=1) Line 30 C++
chap8.1.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C
chap8.1.exe!wWinMainCRTStartup() Line 182 C
kernel32.dll!7c817067()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
The path of execution, includes the following method:
CPaintDoc::CPaintDoc ()
{
m_lineArray.SetSize (0, 64);
}
While the code is dying inside an MFC module, I have to assume that it is not a bug with MFC. Since, I am doing this as a learning exercise, what is the best way for me to debug this?
Thanks
Bob
|
|
|
|
|
I created an environment variable using the Windows System Properties page. In my program I called getenv("varname") to retrieve the value of my environment variable.
After changing the value of my variable, I can see the change when running my program from the desktop but I get the old value when running the program from within MS Vis C++ unless I restart Vis C++. Obviously Vis C++ reads the environment settings and uses them from that point on.
Is there any way to "refresh" the environment from within Vic C++ so that the next time I run my program, it picks up the new value?
Thanks!
jpyp
|
|
|
|
|
jpyp wrote: Is there any way to "refresh" the environment from within Vic C++ so that the next time I run my program, it picks up the new value?
I don't know if there's a way to do that in Visual Studio.
This[^] may at least explain why it happens.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Looks like the only way to get the new value is to read it from the registry. Using regedit I can see the new value under key
HKEY_CURRENT_USER\\Environment\\SSSRights
which has a value of "A".
But there seems to be something wrong with my code becomes I always get a return value of 87 which apparently means ERROR_INVALID_PARAMETER when I call RegQueryValueEx(). hMyKey has a valid handle after call to RegOpenKeyEx().
Here is my code:
HKEY hMyKey;
long lResult;
LPDWORD pKeyType = REG_SZ;
LPDWORD pKeySize = 0;
char* strKeyName = "SSSRights";
char* strKeyVal = "\0";
RegOpenKeyEx(HKEY_CURRENT_USER, "Environment", 0, KEY_QUERY_VALUE, &hMyKey);
lResult = RegQueryValueEx(hMyKey, strKeyName, NULL, pKeyType, (LPBYTE)strKeyVal, pKeySize);
RegCloseKey(hMyKey);
jpyp
|
|
|
|
|
You couldn't possibly compile that
Try
HKEY hMyKey;
if (ERROR_SUCCESS == ::RegOpenKeyEx(HKEY_CURRENT_USER, _T("Environment"), 0, KEY_QUERY_VALUE, &hMyKey))
{
DWORD KeyType;
DWORD KeySize = 0;
TCHAR strKeyName[] = _T("SSSRights");
if (ERROR_SUCCESS == ::RegQueryValueEx(hMyKey, strKeyName, NULL, &KeyType, NULL, &KeySize))
{
<code>
TCHAR *pKeyVal = new TCHAR[KeySize / sizeof (TCHAR)];
::RegQueryValueEx(hMyKey, strKeyName, NULL, &KeyType, (LPBYTE)pKeyVal, &KeySize);
delete[] pKeyVal;
}
::RegCloseKey(hMyKey);
}
Mark Salsbery
Microsoft MVP - Visual C++
modified on Thursday, October 16, 2008 3:51 PM
|
|
|
|
|
Yes it compiled without any errors/problems.
I tried yours and it works but it brings up the following questions:
Why do I need the first call to RegQueryValueEx? What does it do? Why does the first call fail when I provide a buffer instead of NULL?
Thanks!
jpyp
|
|
|
|
|
What compiler are you using?
This line alone won't compile:
LPDWORD pKeyType = REG_SZ; <-- error C2440: 'initializing' : cannot convert from 'int' to 'LPDWORD'
There's several problems
HKEY hMyKey;
long lResult;
LPDWORD pKeyType = REG_SZ; <code><-- wrong data type - should be a DWORD
It's also an OUT variable (if used correctly) so initializing it is pointless</code>
LPDWORD pKeySize = 0; <code><-- wrong data type</code>
char* strKeyName = "SSSRights";
char* strKeyVal = "\0"; <code><-- You need to actually allocate space for the returned characters
Had the query actually succeeded, it most likely would have crashed
trying to write data to a const character array of length 1.</code>
jpyp wrote: Why do I need the first call to RegQueryValueEx? What does it do?
It sets KeySize to the number of BYTES required to store the returned string.
I use that value to know how big the buffer needs to be, which I allocate on
the next line.
You could have just allocated an arbitrary number of bytes, but
you'd get a truncated string if the registry entry was longer than your buffer.
The function is capable of returning the necessary buffer size, so that's the
proper way to do it.
jpyp wrote: Why does the first call fail when I provide a buffer instead of NULL?
Your incorrect use of LPDWORD pKeySize = 0; effectively reults in passing a NULL pointer as the
lpcbData parameter in the RegQueryValueEx() call. That is not allowed - the function
needs to know how big of a buffer it has to return data in and also needs to be able
to set the actual number of bytes placed in the buffer.
Mark Salsbery
Microsoft MVP - Visual C++
modified on Thursday, October 16, 2008 4:35 PM
|
|
|
|
|
I use Studio 6.0 and you are right it does not compile. I had taken out the initialization before in my code but forgot to take it out in my first post here.
I understand now why it wasn't working initially. The size of the buffer must be the same as the value in the last field. I was providing a value of 0 for KeySize because I thought it was a output value only. So only one call is necessary but it is certainly safer to do it your way to get the actual size of the value.
As for the wrong data types, I took those directly from the MSDN library help page. Their data type are LPDWORD for the key type and key size fields.
Thanks a lot for your help!
jpyp
|
|
|
|
|
jpyp wrote: As for the wrong data types, I took those directly from the MSDN library help page. Their data type are LPDWORD for the key type and key size fields.
Are you talking about the parameter types for the RegQueryValueEx() function?
If so, then yes, that is the type of variable that needs to be passed...
that doesn't necessarily mean your variables are supposed to be that type.
For example, a parameter with type LPDWORD - if you read the docs for
that parameter, you'll see wording like "A pointer to a variable that receives..."
or "A pointer to a variable that specifies...". That is NOT what you were passing
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I just tried to use a map and since I don't know how to access an element yet, I thought I'd just set a breakpoint once it's filled and check the contents myself (I randomly assumed that like in VS C# you can see all members of an object at runtime if you set a breakpoint).
However, it doesn't even get there and I get a weird error instead:
Debugging Information for 'Graphics Test.exe' cannot be found or does not match. Symbols not loaded.<br />
<br />
Do you want to continue debugging?
What happened?
Thanks
|
|
|
|
|
Megidolaon wrote: What happened?
You reached what is sometimes referred to as "the limit of your knowledge".
led mike
|
|
|
|
|
Yes...which is exactly why I'm asking what happened... 
|
|
|
|
|
5 .
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]
|
|
|
|
|