|
LCI wrote: If i were using a TCHAR, how would i convert that to std::string.
#ifdef _UNICODE
#define tstring wstring
#else
#define tstring string
#endif
TCHAR szBuffer[1234];
tstring str = szBuffer;
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: TCHAR szBuffer[1234] = _T("David");
in pounds or in Kgs ? 
|
|
|
|
|
I think that std::string is really std::basic_string< TCHAR >, so it automatically becomes the "right kind of" string.
Peace!
-- modified at 14:50 Thursday 1st March, 2007
Well, I guess not... 
Musta been thinking of my own string classes... :P
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
James R. Twine wrote: I think that std::string is really std::basic_string< TCHAR >...
It's std::basic_string<char>, while wstring is std::basic_string<wchar_t>.
James R. Twine wrote: ...so it automatically becomes the "right kind of" string.
Only if _UNICODE is not defined. If it is, wstring must be used.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
James R. Twine wrote: I think that std::string is really std::basic_string< TCHAR >,
Nope[^]
|
|
|
|
|
I totally understand what you are saying in terms of it being a class, but just do not know how to legally get around this.
|
|
|
|
|
toxcct wrote: ...when the function expects a C-style string (array of character).
It actually expects a void* as the second argument. Passing the address of a string object satisfies that requirement. That does not imply that ReadFile() knows what to do with it, however. 
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Any suggestions on how to get around this?
|
|
|
|
|
LCI wrote: Any suggestions on how to get around this?
i already answered this
|
|
|
|
|
DavidCrow wrote: It actually expects a void* as the second argument. Passing the address of a string object satisfies that requirement
yes, it term of syntax, what he does is correct, that's why his program crashed at runtime, not at compile time.
but the function is a C function (win32 API, no ?), so i doubt it would deal with C++ classes
|
|
|
|
|
You are not mixing an exe built in debug and a DLL built in release mode, are you?
|
|
|
|
|
No i am pretty sure that the two are in debug
|
|
|
|
|
Hi all,
If one creates a process in a thread, and that thread ends, would the process end aswell?
Thanx Again
The only programmers that are better than C programmers are those who code in 1's and 0's..... 
Programm3r My Blog: ^_^
|
|
|
|
|
an application have at least one thread, and if you don't create additional threads, you still run in the main thread.
so, when ShellExecute()-ing something in a single-threaded application, does it end when your own app exits ? no 
|
|
|
|
|
O.k so you create more threads, and one of those threads starts a process. So if I understand you correctly, the process won't die if the thread does? If this is the case thank you for the help toxcct.
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r My Blog: ^_^
|
|
|
|
|
Programm3r wrote: O.k so you create more threads, and one of those threads starts a process
not always several threads, but yes, no risk
|
|
|
|
|
Programm3r wrote: If one creates a process in a thread
Wrong usage. Threads are created within the process.
Programm3r wrote: and that thread ends, would the process end aswell?
Again. But yes, all threads end "abnormally" when the process exits without closing it's worker threads properly leading to crashes.
Press: 1500 to 2,200 messages in just 6 days? How's that possible sir?
Dr.Brad :Well,I just replied to everything Graus did and then argued with Negus for a bit.
|
|
|
|
|
Thank you for clearing that one up, I thought it would be a good question to ask, was a bit uncertain about the whole thing....
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r My Blog: ^_^
|
|
|
|
|
VuNic wrote: Threads are created within the process
yes, but executing code is always within a thread (even if the application is single-threaded), so when you create another process, it is always from a thread
|
|
|
|
|
toxcct wrote: so when you create another process, it is always from a thread
Nope Toxcct. It runs outside of the process's(or a thread that created the new process) boundary.
Processes have their own boundary. So closing the thread would never affect a process created by it.
Press: 1500 to 2,200 messages in just 6 days? How's that possible sir?
Dr.Brad :Well,I just replied to everything Graus did and then argued with Negus for a bit.
|
|
|
|
|
The question was about creating a process within a thread, not whether the newly created process will run within the same thread in which it was created.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
 Yup I got the question wrong. Thanks for the reply
Press: 1500 to 2,200 messages in just 6 days? How's that possible sir?
Dr.Brad :Well,I just replied to everything Graus did and then argued with Negus for a bit.
|
|
|
|
|
VuNic wrote: So closing the thread would never affect a process created by it.
you misunderstand me, it's exactly what i said in my first post. reread please
|
|
|
|
|
Here[^]
Press: 1500 to 2,200 messages in just 6 days? How's that possible sir?
Dr.Brad :Well,I just replied to everything Graus did and then argued with Negus for a bit.
|
|
|
|
|
Hello! For couple of weeks I still have a problem with transparent buttons on toolbar. Toolbar background is 24bit image, buttons are also 24bit, VS2003, WinXP.
What I do (background):
1) Load standard 24bit BMP to CBitmap object
2) Create pattern brush based on bitmap from 1)
3) Use FillRect() inside OnEraseBkgnd().
Background is ok, drawing works fine.
Now the buttons:
Solution A:
1) Load 24bit BMP to CBitmap
2) Create CImageList based on 1) using ILC_COLOR32|ILC_MASK
3) Create mask by Add() function with proper RGB() transparent color
4) Use SetImageList() in toolbar control object
RESULT -> NO transparency (round buttons have plain color in the transparent color spots)
Solution B:
1) Load 24bit PNG with transparency to CImage
2) Create CBitmap based on (HBITMAP) operator from 1)
3) Continue steps 2-4 from Solution 1
RESULT -> NO transparency
Solution C:
1) Use CImage like in Solution B but use directly SetBitmap() from CToolbar
RESULT -> again no transparency.
Is there any simple way to get it working?? Basicly I want to have transparent bitmap on buttons. That means, I want to see bankground texture in the 'holes' in buttons (where the button's color == transparent color)
Please, enlighten me I've read many articles and found one solution but it was quite complicated and used many derived classes... ("BitmapToolBarResrch_en" project)
Solution can be Win2k/XP+ for MFC.
Thank a lot!!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
