|
As Joe points out you are trying to create an ASCII string from Unicode. However you are also using a sledgehammer to crack a nut. If you want a pointer to the actual C-style string that is contained within a CString you just need to use the correct operator thus:
LPTSTR tString = m_strFileName;
LPWSTR wString = m_strFileName;
LPSTR aString = m_strFileName;
Read up on the CString documentation in MSDN for full details.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
In addition to the previous replies, I strongly suggest you read this article[^] which will explain everything you need to know about character encoding.
|
|
|
|
|
I have this dialog window with a progress bar, a couple statics, and two command buttons. I am able to update the text of the labels using SetDlgItemText and then UpdateWindow. When I go to destroy the dialog using DestroyWindow, it just hangs. I do handle the WM_DESTROY message, but it seems that it never gets called. What is going on?
case WM_DESTROY:
if (NULL != hIcon1)
{
DestroyIcon(hIcon1);
}
hIcon1 = NULL;
return TRUE;
SetDlgItemText(hWnd, IDC_STATUS, "Update completed.");
UpdateWindow(GetDlgItem(hWnd, IDC_STATUS));
DestroyWindow(hWndPanelTwo);
modified 21-Dec-20 21:02pm.
|
|
|
|
|
Without seeing more of the dialog code, this is just a guess, but do any of your command buttons make a call to EndDialog? That should trigger the WM_DESTROY. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
This is not the way to terminate a Dialog, you should just use the EndDialog() call.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
This dialog doesn't have a command button that calls EndDialog(), but I have other dialogs that do and I've successfully been able to terminate them using DestroyWindow().
modified 21-Dec-20 21:02pm.
|
|
|
|
|
I think I've forgotten to tell you that this takes place in a different thread than the one that hWndPanelTwo was created. After looking at the MSDN Reference pages, a found a small note that said why the dialog wasn't destroyed:
Remarks
A thread cannot use DestroyWindow to destroy a window created by a different thread.
So my question becomes how can I destroy this window from within a different thread? EndDialog won't work becuase I used CreateWindow to create the dialog.
modified 21-Dec-20 21:02pm.
|
|
|
|
|
Well, as the documentation clearly states, you cannot. You should not be using cross-threaded code in this way, create your dialog in one thread and ensure it is destroyed by that same thread. If you don't follow the rules you will find things don't work.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
Okay then, so is there any way to figure out that the other thread has ended and then destroy the form using DestroyWindow()?
modified 21-Dec-20 21:02pm.
|
|
|
|
|
Presuming this part of your code is in the WindowProc for hWndPanelTwo
case WM_DESTROY:
if (NULL != hIcon1)
{
DestroyIcon(hIcon1);
}
hIcon1 = NULL;
return TRUE;
add this
case WM_APP:
DestroyWindow(hWnd);
break;
and modify this as follows
SetDlgItemText(hWnd, IDC_STATUS, "Update completed.");
UpdateWindow(GetDlgItem(hWnd, IDC_STATUS));
PostMessage(hWndPanelTwo,WM_APP,0,0);
|
|
|
|
|
I may be mistaken but I get the feeling that you are using a modal dialog where your requirement is for a modeless one. Take a look at the MSDN documentation on Dialogs to see if there is a better option for you that will not require multiple threads.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
Hi ,
I am using 2 dlls which are having two namespace with the same name in it. If we import these two dlls in a new class and tried to access a variable in any one of the namespace from those 2 dlls, Will there be any namespace collision? if yes how can I avoid that
Thanks in advance
|
|
|
|
|
if they both have namespaces (and hopefully different ones) , then use the namespace when accessing data from either of them.
for example :
dll1_namespace::classA::myData;
dll2_namespace::classA::myData;
Watched code never compiles.
|
|
|
|
|
If they have the same namespace then there is a potential for collisions if namespace::class::method all have the same name. If this is a problem for you then you need to change some of the names.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
Does this[^] help?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
>Nothing is free in the universe.<
|
|
|
|
|
|
What are the diffrent ways by which we can access a dll and lib in an .exe
|
|
|
|
|
can you explain what you mean ?
Watched code never compiles.
|
|
|
|
|
I am going to use some thirdparty dlls and lib files in my applications exe. What are the possible ways by which we can access those dll or lib in my exe. Can we simply use LoadLibrary or #import or any other way. Which will be the ethical way to achieve this
|
|
|
|
|
You can link the libraries to your executable code or use LoadLibrary to access them dynamically. There is no 'best' method, just do it the way that is most convenient for you.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
|
Is there any way to use SHGetFolderPath() to get the path to the C:\Documents and Settings folder? With Vista and newer, I can use SHGetKnownFolderPath(FOLDERID_UserProfiles, ...) to get the path to the C:\Users folder, but I need an XP solution.
Thanks.
- DC
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I can think of a way to achieve it using SHGetFolderPath(). If I pass the corresponding value of CSIDL[^] to get the public desktop, the API should return something like C:\Documents and Settings\All Users\Desktop, which I can strip down to C:\Documents and Settings.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
I thought of that, but was not sure that "All Users\Desktop" would always exist (e.g., spelling, locale). Maybe I can key off of the backslash instead.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
You could also use SHGetSpecialFolderPath() and pass CSIDL_APPDATA to it. This would give you something like "D:\Documents And Settings\Administrator\Application Data". The AppData folder always exists as far as I know.
Go and never darken my towels again - Groucho Marx
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
