|
Hi,
I'm loading resource>toolbar into CImageList
When i draw using imageList.draw, then the transparent is no more work
any idea?
CImageList ImgList;
COLORREF rgbTransparentColor = RGB(73,73,73);//dono what this use..
CBitmap bmp;
int bubu = bmp.LoadBitmapW(IDR_MAINFRAME);//the toolbar to be loaded
ImgList.Create(16.5,14.5,ILC_MASK | ILC_COLOR32,1,1);
ImgList.Add(&bmp, rgbTransparentColor);//put the bitmap into imagelist
CPoint ptImage(rectIcon.left + 1, rectIcon.top + 1);//get the point(position) of the rectangle to be drawn
ImgList.Draw(pDC, nIconPosi, ptImage, ILD_NORMAL);//draw the icon
good
|
|
|
|
|
karhong wrote: RGB(73,73,73);//
Is this the color in the bitmap that you want to make transperent?
|
|
|
|
|
yea.. i hope to make the imgList.Draw icons to have the background color of RGB(73,73,73)
good
|
|
|
|
|
Either I am misunderstanding you, or you are misunderstanding the API.
The transparent colour is the colour in the original bitmap that you want to become transparent.
I normally use a hideous shade of purple, or pink. I'm too manly to use them for actual display. There is nothing stopping you using a certain shade of gray (RGB(73,73,73)), but it will be less obvious when you are editing the original bitmap.
For debugging the sort of problem you have, I strongly recommend the excellent article http://www.codeproject.com/KB/applications/imageviewer.aspx[^] by PJ Arends.
Iain.
Codeproject MVP for C++, I can't believe it's for my lounge posts...
|
|
|
|
|
Hi all,
We have a situation where we need to check that the 'this' pointer is not null in a (non-virtual) member function. The problem is that the class it is in is sometimes involved in a multiple inheritance hierarchy where it is not the first base class and thus the 'this' pointer is adjusted by the compiler before it is given to our function. I've read that "some" compilers will explicitly check for null "this" pointers and not adjust them to prevent this issue; however, it does not seem that MSVC++ 9 behaves this way. Is there by any chance a flag that can be set to enable this behavior?
If there is not, what suggestions do you have on a way of reliably detecting this situation? One thought is to simply compare vs a sufficiently large value such that any offsets would be well within the range - perhaps the system reserved memory range (0 - 0x0000 FFFF). Any others are welcome. Thanks in advance.
|
|
|
|
|
I suspect any this value below the standard start address for an EXE (0x400000, IIRC) is suspect.
BTW - what's the rationale for allowing NULL this pointers in this case? That sounds like something you'd prefer to avoid if at all possible...
|
|
|
|
|
Thanks for the suggestion.
We have a large and complex set of classes which are frequently built using composition and a variety of design patterns. One of the things we're looking for is essentially C#'s is operator only customized to our types. Like the is operator, we'd like to be able to handle NULLs. It's not a hard requirement, but it makes use of the new functionality simpler and more straightforward. 
|
|
|
|
|
How about dynamic_cast?
if (dynamic_cast<basetype*>(SomePointer)) { }
Consider this code:
#include <iostream>
class Base1
{
public:
virtual DoSomething1() const { std::cout << "Base1::DoSomething1 @ " << (int*)(this) << "\n"; }
};
class Base2
{
public:
virtual DoSomething2() const { std::cout << "Base2::DoSomething2 @ " << (int*)(this) << "\n"; }
};
class Base3
{
public:
virtual DoSomething3() const { std::cout << "Base3::DoSomething3 @ " << (int*)(this) << "\n"; }
};
class Derived : public Base1, public Base2
{
public:
virtual DoSomething1() const { std::cout << "Derived::DoSomething1 @ " << (int*)(this) << "\n"; }
virtual DoSomething2() const { std::cout << "Derived::DoSomething2 @ " << (int*)(this) << "\n"; }
};
int main(int, char**)
{
Derived d;
std::cout << "d @ " << (int*)(&d) << std::endl;
std::cout << "dynamic_cast<Base1*>(&d) == " << dynamic_cast<Base1*>(&d) << std::endl;
std::cout << "dynamic_cast<Base2*>(&d) == " << dynamic_cast<Base2*>(&d) << std::endl;
std::cout << "dynamic_cast<Base3*>(&d) == " << dynamic_cast<Base3*>(&d) << std::endl;
std::cout << "dynamic_cast<Base1*>(0) == " << dynamic_cast<Base1*>((Derived*)0) << std::endl;
std::cout << "dynamic_cast<Base2*>(0) == " << dynamic_cast<Base2*>((Derived*)0) << std::endl;
std::cout << "dynamic_cast<Base3*>(0) == " << dynamic_cast<Base3*>((Derived*)0) << std::endl;
return 0;
}
We get this output:
d @ 0012FEDC
dynamic_cast<Base1*>(&d) == 0012FEDC
dynamic_cast<Base2*>(&d) == 0012FEE0
dynamic_cast<Base3*>(&d) == 00000000
dynamic_cast<Base1*>(0) == 00000000
dynamic_cast<Base2*>(0) == 00000000
dynamic_cast<Base3*>(0) == 00000000
So dynamic_cast indicates inheritance relationships with a NULL and will also detect null 'this' pointers properly.
|
|
|
|
|
I am currently writing an application using C++ and MFC. It has three threads. One is for the GUI interface and the other two (worker threads) do the same simulation many times. When one of the worker threads completes a simulation, it sends a message back to GUI thread, via SendMessage.
I am counting the number of messages that I am sending and the number of messages that the GUI thread is sending, and they are not the same. When I put a sleep statement in the worker thread, the problem goes away. I am thinking that I am overflowing the window’s message queue. Is there a way to verify this or to find out how many messages are in the queue at a given time? I am also wondering how big the queue is. I am using this message to return results. I am starting to think this was a bad design decision. Please comment.
Thanks
Bob
|
|
|
|
|
Hi,
IIRC some messages get special treatment; e.g. WM_PAINT messages may get merged if all they do is request a repaint of (parts of) the same Control. Maybe it is also true for setting a text to a label,
etc.
Your app is also likely to get some messages from the outside world (device inserted, task manager checking for "not responding", etc).
if you suspect your queue is "filling up", the design is not OK; what will happen if your system gets another load at the same time? what if your app needs to run on a slower PC?
When you have a progress bar showing a progress say in percent, then it does not really make sense to send it 10,000 progress updates, it probably can only show 100 or so different states anyway; so you should consider a cheaper way of reporting, probably by aggregating a number of progress steps.
Do you really need that much GUI activity; after all it is consuming its share of CPU cycles, and hence slowing down the simulation of which you are eager to know the progress!?!?
One way I often handle these kinds of requirements is by having the background doing its job without reporting anything, and having one more thread which periodically (a few Hz) reports the progress by
looking at the backgrounder state variables (if they are simple enough, that does not require any
synchronization, locking, whatever...)
|
|
|
|
|
Luc,
Thanks for the response. As it turns out, the problem is not any worse with a heavily loaded system. With sleep statements in the worker threads and a heavily loaded system, no messages are lost.
I am thinking that using the Window's messaging approach to return results is not the way to go. Please comment.
Bob
|
|
|
|
|
What we did to avoid this was to ...how to say... delay updates of the GUI. How to explain, if there were a 1000 things needed to be updated on the GUI, instead of sending 1000 messages towards the GUI we started putting them in a packet, if a packet had 100 objects in it, we would send this towards the GUI, if a packet had less than 100 objects in it but a given time had passed since the last time a packet was sent, we sent the not-full packet.
Also, as Luc Pattyn said, polling can also help solving your problem.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
Thanks for the response. However, my current requirements state that I cannot batch them up. However, I can work on getting that changed. Would do you think of the idea of return results by calling a method in GUI interface? Of course, there would have to be a lock on the method so that no two threads could update the GUI at the same time.
Bob
|
|
|
|
|
BobInNJ wrote: ...no two threads could update the GUI at the same time.
Secondary threads should not interact with IO components owned by the primary thread. You should post the message(s) to the primary thread instead.
"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
|
|
|
|
|
You mean polling? The GUI thread periodically asking for the values needed?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
Thanks for the response. I do not mean polling. I mean that the worker threads calls a method in the GUI object to report the next result. This is how I originally wrote the code. The problem with this approach is that two threads could be updating the object at the same time. This can cause a problem. In fact, I posted this problem to the group earlier. There were two suggestions. One was to use a lock, the other was to use SendMessage. I choose the second option. I am not thinking I should have chosen the first.
Any comments?
Bob
|
|
|
|
|
I remember your post about this, but wouldn't that method that gets called update the GUI? If not, then i misunderstood you...if it doesn't actually fiddle with windows then the lock-aproach is better. However, if you want to fiddle with the gui, like redrawing counters, you either have to use messages as you tried (but if there are a lot of the messages, as you experienced, this can cludge the GUI) or use polling.
On a different aproach, you might place Sleep(0) or Sleep(1) in your secondary threads at the right places to give other threads the chanche to do their business but of course this might produce slowdown of the whole thing.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
BobInNJ wrote: ...the other was to use SendMessage.
Which was a bad suggestion.
"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
|
|
|
|
|
I believe using SendMessage or PostMessage for my application is not the way to go. I am not saying that it was a bad suggestion just that in my case it did not work out.
Bob
|
|
|
|
|
What do you think of the idea of lowering the priority on the threads that are doing the computation? That way, I can be sure that GUI thread can keep up and the queue will not over flow?
Thanks
Bob
|
|
|
|
|
BobInNJ wrote: lowering the priority on the threads
Never alter the priority of any thread until you know exactly where your bottlenecks are by measuring, and even then it suggests a poorly designed application.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
I have to agree with Roger Stoltz there, finetuning threads by changing priorities can be a very difficult task and it probably would lead to different reasults on different systems..
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
I would like to say that I am learning a great deal about threads and locks in this discussion. I would like to thank everybody who responded to my posts. Here is the revised plan for the reporting function in the GUI interface:
<br />
void<br />
GUIClass::repFunction( struct ReportData repData )<br />
{<br />
if ( WaitForSingleObject(mutexHandle, INFINITE) == WAIT_OBJECT_0 ) {<br />
copy repData to this class<br />
add 1 to a counter<br />
if the counter % 4 == 0<br />
generate a WM_PAINT request<br />
end if<br />
ReleaseMutex(mutexHandle);<br />
}<br />
<br />
}
The data item mutexHandle is a member of the class GUIClass and is defined as follows:
HANDLE mutexHandle;
In addition, it is initialized in the constructor for GUIClass as follows:
mutexHandle = CreateMutex( NULL, FALSE, NULL );
Now, does anybody see any problems with my design? I am not convinced that I have the arguments
to CreateMutex right? One last thing, I have a prototype of my application, and the following reporting function is working in the prototype.
Thanks
Bob
|
|
|
|
|
BobInNJ wrote: I am thinking that I am overflowing the window’s message queue.
Doubtful, since you are bypassing it by using SendMessage().
"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
|
|
|
|
|
David,
Thanks for the response. How can I verify whether or not the message queue is full? Is there a call to find out how many elements are in the queue?
Bob
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
