I very rarely use it to fix minor typo-like errors, such as replacing < with <=, or changing literal values in assignments or function calls to something else. The reason is that I'm often confronted with deep levels of function calls with multiple nested loops, and getting back to the same point of debugging can be very time consuming.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
I would neither store nor return the bitmap data in that way. What you are creating here is a so-called "ragged" array, in which each row can have a different length. In a bitmap this luxury is not needed, all rows are of equal length by definition. Therefore a one-dimensional array is good enough and in some regards even superior.
a) A one-dimensional array can be allocated in one chunk (whereas your ragged array needs N allocations, N being the number of rows)
b) A one-dimensional array does not incur the overhead that comes with a ragged array, which is easily 3 x 64bits per row.
To access the members of the one-dimensional array in a 2D fashion, simply use the algorithm:
index of pixel (x, y) = x + y*pixelsPerRow
As a return value for your access function I would suggest you use a simple pointer (const COLORREF*).
For the caller to know how to access that 1D array you should provide addition access functions for the number or rows and number of columns.
Ohh, I would love to get rif of 2D array ... I had taken the class from here[^], could you assit me how to give up vector> BitmapData ? If I am not asking too much ... I will start working, to see what is happen ... See you.
DLLs also help reduce memory overhead when several applications use the same functionality at the same time, because although each application receives its own copy of the DLL data, the applications share the DLL code.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
Thank you for answer. But if two dlls(having same signature) in two different directories and linked by tw different executable. Then what will happened? Is the design same across different OS.
There's an order by which exe's look for libraries. It will use the first one it finds, I believe CPallini gave you a link that specifies the search order. You can use tools such as Dependency Walker[^] to see what dll specifically is getting loaded by an exe if you're not sure which one it's loading. It is customary that shared dll's are placed in a location where any program that wants to use it has access to it, of course, this will require admin privilidges for your installer (assuming you place the dll copy in a system folder).
As far as object data (memory), that's not shared at all.... it's just the code that is shared. For example, if you have two exe's using an IO dll, the state of one will not affect the other, they're still independent while running. If you want them to share something, you have to set that up using other means (IPC).
I have Visual studio 2005 on WIn7 system. Project dependencies and Buildorder everything is in place and correct.
But it is not Building according to build order correctly when doing clean and Rebuild.
I checked with other win7 sytem it is doing properly there.
It could be because parallel compilation is used on a multi core machine. If two projects are not strictly dependent, they can be built in parallel.
If you wanted to enforce the build order (including single thread compilation), you could set the dependencies in a single row even though theprojects don't really depend on each other. But why would you want to do this?
The good thing about pessimism is, that you are always either right or pleasently surprised.
If build order is important, then specify project dependencies. That should make the build order exactly the same every time.
If memory serves right, in a multi-project solution, you can right click on a project and set dependencies within the menus there. When you make one project dependent on the others, Studio will build the dependencies first.
We would call this a system modal situation, but there is a twist - I have no source code for the application in question (so, no ::SetWindowPos).
The big picture - my application is running, and it's full screen. Think of a kiosk like application... no window manager, no task bar, no keyboard. Should the user choose to, they can invoke a calibration utility for the touchscreen. When calibration is complete, the utility helpfully posts an AfxMessageBox("Calibration complete"). Here's where my woe begins...
If the user is careful, they can press the acknowledge box and the utility terminates. Choose poorly, and the application pops up over the dialog, effectively causing a blocking window inversion.
I think I can work around this by not blocking with the CreateProcess call, but I haven't tried it yet. So, any other ideas? I'm going to write the oem for a variation on the utility, but I don't have much hope there.
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
You can still use SetWindowPos.
You just need to get the handle to the message box. FindWindow will get you this handle.
The best way would be to install a shell hook using SetWindowsHookEx which will then give you a notification when the message box pops up and also its handle.
You could then use SetWindowPos on the handle to make it top most.
It is for you to decide if it is worth installing the shell hook because it will effect the entire system.
«_Superman_» I love work. It gives me something to do between weekends.
You could do your own calibration or have vendor remove dialog box. Failing that, when the calibration utility is started, you could have a thread monitor windows ans when that window pops up, either force it to the foreground or just close it yourself.
Where it gets tricky is that only the current active, foreground application can make another application the foreground and despite appearances, who is this application isn't always straightforward. To get around this for one project, I ended up writing the following (The W is the prefix for my personal, but in-the-public-domain, library:
// Load bitmaps from resource. Both m_CheckBitmap and m_UnCheckBitmap
// are member variables of CMainFrame class of type CBitmap.
// Associate bitmaps with the "Bitmap" menu item.
CMenu* mmenu = GetMenu();
CMenu* submenu = mmenu->GetSubMenu(4);
But i think my situation is more easy than example, but maybe i have problems to merge the two code parts,
please can you help me i don't think take you more time.
Thanks very much.
According to the documentation[^], the bitmaps are just used to indicate the item is selected or not. The MSDN sample shows you how to add the two bitmaps to your menu items. When you say you just want icons, do you mean without any text? If so you need to look at http://msdn.microsoft.com/en-us/library/kb145b0a.aspx[^], for the options to set up individual menu items.