Showing tag results for Code

The window manager and GDI objects as a general rule will automatically destroy objects created by a process when that process terminates. (The window manager also destroys windows when their owner threads exit.) Note, however, that this is a safety net and not an excuse for you to leak resources in your own program with the attitude of "Oh, it do...

GDI objects are much simpler. As a general rule, they all have process affinity: They can be used by any thread in the process that created them. If you use a GDI object from multiple threads, it is your responsibility to coordinate the object's use. Note that the window manager and GDI as a general rule keep their respective objects thread-safe....

The remaining user interface objects in common use are menus, icons, cursors, and accelerator tables. Menus do not have thread affinity. Any thread can use a menu. However, if two threads use a menu, it is the responsibility of those threads to coordinate among themselves how that menu will be used, so that one thread doesn't modify a menu while ...

Last time, we discussed briefly the thread affinity rules that govern window handles. Device contexts (DCs) also have a certain degree of thread affinity. The thread that calls functions such as must also be the one that calls , but as with window handles, during the lifetime of the DC, any thread can use it. If you choose to use a DC in a mul...

Different objects have different thread affinity rules, but the underlying principles come from 16-bit Windows. The most important user interface element is of course the window. Window objects have thread affinity. The thread that creates a window is the one with which the window has an inseparable relationship. Informally, one says that the th...

My colleague Marc Miller wrote up a brief essay on the subject of dealing with a neutral apartment that has been injected into your single-threaded apartment: COMmunism: Sharing your Apartment. Highly recommended.

Some people have noticed that if you load a DLL with the flag, you sometimes get strange behavior if you then pass that to a dialog box function. The problem here is that since the bottom 16 bits of a proper are always zero, different components have "borrowed" those bits for different purposes. The kernel uses the bottom bit to distinguish mo...

More often I see the reverse of the "Low priority threads can run even when higher priority threads are running" problem. Namely, people who think that is a clean way to yield CPU. For example, they might have run out of things to do and merely wish to wait for another thread to produce some work. Recall that the scheduler looks for the highest...

Just because you have a thread running at a higher priority level doesn't mean that no threads of lower priority will ever run. Occasionally, I see people write multi-threaded code and put one thread's priority higher than the other, assuming that this will prevent the lower-priority thread from interfering with the operation of the higher-prior...

One commenter claimed that When the object is first constructed, the reference count should be 0 and AddRef should be called at some point (probably via QueryInterface) to increment the reference count. If you construct your object with a reference count of zero, you are playing with matches. For starters, when the object is created, there re...