|
You don't think I actually test some of my answers, do you ? 
The MSDN sample doesn't use a bitmap because it's using a window DC, not a compatible one, so I was guessing that over-eager clipping was responsible.
"When the memory DC is created, its display surface is exactly one monochrome pixel wide and one monochrome pixel high. Before an application can use a memory DC for drawing operations, it must select a bitmap of the correct width and height into the DC. To select a bitmap into a DC, use the CreateCompatibleBitmap function, specifying the height, width, and color organization required".
Interestingly, the same documentation doesn't mention what the default font for the memory DC is, but there ought to be one.
Can't help with the OS question, since I'm XPSP2 everywhere except servers these days.
Steve S
Developer for hire
|
|
|
|
|
No worries. My first attempt to to use the window DC, but since that wasn't working I thought maybe it was something to do with the clipping regions I had already selecting into the DC. So I tried it out with a compatible one. But as you can guess, that didn't work either.
Regarding the DrawText() api, I might not even need to use it. It would probably be easier to use TextOut() to calc the region, then offset that region to wherever I need it. Instead of later drawing the text, I can simply fill the region.
|
|
|
|
|
I managed to narrow the problem down to not selecting a font into the DC before opening the path bracket. Even though the docs for TextOut() state it will use the system font. I guess it is because there is no real drawing going on. Not a big problem since I was meaning to add support for fonts anyway.
Now I have another question. MSDN gives a list of drawing functions which can be used in combination with path brackets for each OS. TextOut() and ExtTextOut() are in the list, but DrawText() is not there. Nontheless I tried it and it worked ( I'm running XP sp2 ). Does anybody know if this is supported on other OS's?
|
|
|
|
|
If I have a base class pointer &
want to call the Destrutor of the dervied class.
How do i do that ?
Vikas Amin
EATON
PUNE
|
|
|
|
|
Make ur destructor virtual and just use delete operator on base class pointer.
U can also call destructor manually using downcasting by converting base class pointer to derived class pointer.
Karnav Zaveri
|
|
|
|
|
How to get handle for all the open Child windows?
Thanks
Raji
|
|
|
|
|
Is EnumChildWindows helpfuls ?
|
|
|
|
|
Hi,
I've got 2 threads, one continuously uses "SendMessage" to tell main thread to perform some processing and update the GUI.
However, after running my application for anywhere between 1/2 hr to 5 hours, SendMessage will randomly get stuck.... IE: The window that's suppossed to receive the message never receives the message, and the application GUI just freezes.
Can anyone tell me if this has happened to them before, or what could possibly cause the message sent by SendMessage to not-be-received by the recepient window?
Thanks,
skyapie 
|
|
|
|
|
Its called a deadlock and your thread synchronisation is not working correctly, SendMessage() will wait until the message has been processed before returning, you could try PostMessage() instead which will not wait but I would check your thread synchronisation first.
Darka [ Xanya]
"I am not a slave to a god that doesn't exist."
|
|
|
|
|
skyapie wrote: I've got 2 threads, one continuously uses "SendMessage" to tell main thread to perform some processing and update the GUI.
Secondary threads should post messages (i.e., PostMessage()) to the primary thread.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
As has been said, never use SendMessage() to send messages between threads. Use PostMessage() instead. If you really need the return value from the message then you can use SendMessageTimeout().
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Hello all,
did anyone wrote a CStringTable, similar to the CStringArray class from MFC? Thanks in advance.
|
|
|
|
|
Hi,
list< CSting > or list< string >
vector< CString > or vector< string >
-----------
Mila
|
|
|
|
|
Thanks for your quick answer but ... what you suggested me, if I understood right, is to use list<cstring> instead of MFC's CStringArray. I would like to use a CStringTable like CStringArray[nColumnCount], with the proper interface to that. Has anybody did that before, or I just start from scratch? Thanks again.
|
|
|
|
|
oh, ok, you need something like :
MFC:
CArray < CStringArray >
STL:
std::vector < std::vector< std::string > >
|
|
|
|
|
Hi,
my question was similar to Maximilien' question - What are you trying to achieve with this new class ? ... But now I think if you try to do something fast, secure and with pretty simple methods it would be good. Problem with CStringArray and generally with CString from MFC is, that operations on it take many many many time (I mean by processor).
-----------
Mila
|
|
|
|
|
What is the difference between the 2 ?
What are you trying to achieve with this new class ? that it is not MFC dependent ?
|
|
|
|
|
Hi.
I am using Windows xp OS and I have created an application in VC++.
When I execute it, what I see is the basic display properties of the controls. What I what is to display the controls in my application in same way as they appear on XP.
For example, check mark in check boxes appears in green color while it appears in black color in my application.
How can I achieve the XP like display of my controls?
Thanks
Sameer
Sameer
|
|
|
|
|
|
Hi Benjymous
Thanks for help.
It worked.
Thanks again
Sameer
|
|
|
|
|
hi all
how to konw that a COM Object support multithread or not
thanks
shadrach
|
|
|
|
|
Hopefully the writer of the object put the proper restrictions on the object.
If it is not multithread aware, then it will only be allowed to be created in a Single Threaded Apartment (STA), then if you try to talk to multiple COM objects on different threads, the COM architecture will protect and syncrhonize those objects.
Otherwise, a COM object will be thread safe if it is allowed to run in the Multi-threaded Apartment(MTA) or the Free Threaded Apartment. In this case, the object itself must syncrhonize the internal state data to properly run.
When you create a COM object, you specify the type of thread that it is created on. If the thread that you are attempting to create the object on is not compatible with the supported apartment types for the COM object, the object creation should fail.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
In general you should have to worry. As long as you marshal interfaces pointers between threads COM should take care of the details.
Steve
|
|
|
|
|
How to access *.mdb data in a MFC Dialog based application....
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
