I am using a ListBox and add Variable derive of CCheckListBox.i use a Check box that is use to select and UnSelct all items of ListBox.i handle it over ON_LBN_SELCHANGE of ListBox and Click event of Check box.
Selection and UnSelection from Checkbox working fine.
But problem occur when i use it by List box.i want to do when the all items of list box is checked then Select all Check box automatically Checked or vice-versa.
Code is here
Properties setting of List Box Has String is TRUE,Owner Draw is FIXED,Selection is Multiple.
Problem is that when first time click on listbox then OnLbnSelchangeListColumns() is call and when i click on listbox on second time then OnLbnSelchangeListColumns is not call.
Plz help me
i used print function in my application it will print the contents of richedit control but i want to print whole dialog along with button and richedit control content in vc++,mfc.Anyone who knows this please help me.
Hi. Well.. another time when i need help. I am trying to create a map (made of MPictureBox(my class derived from CButton)) in a thread. I am creating modal window and clicking "ok" button and creating map on my main window (CDialog). When i did it without threads all worked just fine. But when i put the creation in a thread it make it all very well... BUT! created buttons don't show up in the main window! (they exists in the memory but didn't show). I was thinking that probably it's some kind of problem related to using main window with different threads so i wrote this
with 0 effect. Same trouble i had when i tryed to create some dynamic objects (with "= new ..."). Somebody had same trouble? What's the problem? (When i do the same thing without any thread it all results okey).. Pls help.
If this is MFC then its Window Maps are created per thread and a CWnd* object in one thread is not (easily) accessible in another. So doing UI stuff in worker threads is difficult. It is much easier to do this in the main app thread, and shuffle off any lengthy non-ui processing to worker threads.
Well.. thnx for the info it helped a lot. Now i am using UI-thread. And post messages to thread, etc. And it's all cool. It works. It creates the map of buttons and etc. BUT the problem hasn't been resolved. Buttons doesn't appear on the screen! They are created in memory but doesn't appear. Like i said the same trouble i had with pointers. I create pointer theApp.object = new CObject(...). Then theApp.object->Create(..) and theApp.object->ShowWindow(SW_SHOW) and it didn't show up. But if i write CObject globalobject; and then Create it, it appears correctly. I don't know how is that previously it worked with theApp.lvl = new ... but now it doesn't. But it all exists in the memory. I don't understand.
I noted that the objects actually works. I can click them, but the objects doesn't draw itselfs.
I'm looking for some C++ code to let me quickly move a bitmap around a window, restoring the background as it moves. At present I capture the Window contents to a bitmap during the app initialization and in the OnPaint() I draw the this bitmap and then I draw my overlayed bitmap. I am double buffering the paint. The overlayed bitmap position moves with the mouse which invalidates the Window.
This works fine except it is too slow when the background window is large (think Windows Desktop) and the PC is slow. My guess is that redrawing the large background bitmap on every mouse move is the bottleneck. There has to be a much better and faster way to do this, but my searching hasn't found the answer I need.
if the background is static, you really only need to draw the overlay at its new position and then draw the parts of the background that were uncovered when the overlay moved. there's no need to redraw the whole background.
1. the overlay's previous rect = R1.
2. the overlay's new rect = R2.
3. R3 = the bounding rect of R1 and R2.
4. alloc a bitmap of size R3
5. fill it with the appropriate chunk of background
6. draw the overlay into the temp bitmap
7. draw the temp bitmap to the screen
as long as the overlay is moving only a few pixels at a time, R3 should be just slightly bigger than the overlay size. if R1 and R2 don't instersect, you can split it into two operations: restore the background to one rect, then draw the overlay into the other - don't bother with the temp bitmap.