|
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!!
|
|
|
|
|
there's a classic KB article (#79212) that gives the steps for a transparent Blt. but, it looks like MS has lost it.
but, Google knows where to find it.
|
|
|
|
|
Thanks for reply I've read this article... It means, I have to override WM_PAINT message and blit buttons by myself? Is there any way to 'prepare' somehow my bitmaps that Windows could draw them with transparency by its own routines, like it does for non-transparent toolbar buttons???
Ok, let's assume using WM_PAINT message, now I dont need WM_ERASEBKGND handler and should draw background and buttons in a single OnPaint handler?
Thanks again
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
