|
learn C++ is not by only reading boooooks .
you must think like a programmer and understand the idea behind the code .
|
|
|
|
|
an exe or dll is in memory buffer downloaded from website.
How to get the exe or dll version info from memory buffer directly?
I don't want to save it then retrieve version info from the saved file.
Is it possible? How?
|
|
|
|
|
Yes, it is possible, but quite fiddly. If it's at all possible to save the files and using the Windows API function GetFileVersionInfo I recommend doing that.
If not, you can dig into the details of "PE", or the Win32 Portable Executable File Format which describes where to find the version information, among many other things. It's quite a hassle though.
|
|
|
|
|
There is probably some C/C++ code that does this, but so far I have only seen an implementation in PHP. Maybe you could just translate this to C/C++.
|
|
|
|
|
j_schultz wrote: ...so far I have only seen an implementation in PHP.
Which requires the info to be on disk, yes?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
It should be simple to rewrite the implementation to work with normal memory chunks instead of real files - as the downloaded file should be in some kind of byte array, you can emulate the fseek / etc. calls by simply advancing a pointer in this array.
|
|
|
|
|
I'm pretty sure I've seen images with little fields for writing text before. I'm wondering how hard that is? Does it take very long to pull off?
I'm an aspiring board game / RPG designer and I want to go completely digital so I'm going to need image files where players can input data. Could you give me some info on this? Maybe tell me where some tutorials are for this sort of thing?
If I was going to pay to get a single page with say 50 different entry slots how much should that cost me?
Thanks
|
|
|
|
|
Show us a screenshot -if possible- of what you mean because your description is a bit vague.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
I have a project that seems to have quite some trouble with MFC. First off, the code base is quite old, the earliest GUI code is from around 1997. It's a MDI GUI with a splitter pane, and in the upper panel, some MFC controls disappear all the time since I switched from VS2003 to VS2008/VS2010. They do not disappear all the time, and it's not always the same controls that disappear. In the worst case, the window can look like this while it's supposed to look like this. Clicking the invisible controls makes the visible again.
Do you have any idea what could be causing this?
Edit: I should also add that "switching" to the tab using a shortcut when you already are on the tab makes the combo boxes visible, but without their border, just the white edit part of the combo box (the dropdown button is also missing).
modified on Tuesday, August 30, 2011 4:50 PM
|
|
|
|
|
Make sure the group boxes in the dialog has the "Transparent" property set to "true" (Use the Resource Editor to verify this)
|
|
|
|
|
That would have been too easy... Doesn't help. :\
|
|
|
|
|
Check the tab order of the controls, especially if you have group controls ( which you do have).
I don't remember if the group should be before or after the controls that are "inside" it.
Watched code never compiles.
|
|
|
|
|
To make tooltips on controls work, group boxes must have a higher tab value than their content. So all group boxes have a higher tab order in this case.
|
|
|
|
|
j_schultz wrote: To make tooltips on controls work, group boxes must have a higher tab value than their content. So all group boxes have a higher tab order in this case.
Are you sure that is that true? It's been a long time since I've dealt with tooltips (in MFC), but I don't remember that restriction. I think the only side effect of having the group boxes be lower in the tab order than their content would be that they could right click on the group box to get "What's This" on whatever the next control in the tab order is. It would be interesting to see if that fixes the disappearing problem, even if it's not satisfactory.
Have you tried programatically bringing the disappearing controls to the front by using SetWindowPos(HWND_TOP, etc.)?
|
|
|
|
|
Yes it is true. I have had issues with tooltips not appearing at all, and the solution was to change the tab order. And as said in another reply, removing the boxes alltogether does not fix the problem, either, so changing tab order will not fix it either as well.
|
|
|
|
|
Have you tried programatically bringing the disappearing controls to the front by using SetWindowPos(HWND_TOP, etc.)?
|
|
|
|
|
I have tried using MFC's BringWindowToTop() on the combo boxes in OnInitDialog() and in the page activation code, but sadly that doesn't help, either.
|
|
|
|
|
I have kind of found a way to fix it now. I'm calling Invalidate() in the page activation code, and it seems to help. Interestingly, before doing so, the combobox that disappeared most didn't disappear anymore when I removed the code in the page activation code that was responsible for filling the combo box - which is weird, it just calls ResetContent and AddString...
|
|
|
|
|
David Kentley wrote: Are you sure that is that true? It's been a long time since I've dealt with tooltips (in MFC), but I don't remember that restriction.
Yes, z-order can make or break tooltips.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
DavidCrow wrote: Yes, z-order can make or break tooltips.
Yes, but I thought if a right click was pressed on a control, that control would be checked for a tooltip. If that didn't have one, it would look at the next one in the tab order, and so on, until it found a tooltip. So if I had a groupbox as the first in the tab order, then a static control, then an edit control that has a tooltip associated with it, I can right click on any of the three to get the tooltip.
To bring it back to the original question, wouldn't re-ordering them in this way at least be a way to see if it fixes his disappearing controls. If he doesn't want the groupbox to ever have a tooltip associated with it, it needs to be the last in the tab order (which is why I guess he's doing that), but that messes with the z-order.
That's why I had the SetWindowPos solution as well. This is one of those things that I spent years dealing with, and I thought I had a pretty good system for it, but it's been a long time since I've worried about it. I just realized I've been talking about context sensitive help and this has been about tooltips. 
There are similar issues involved, though, involving tab ordering.
|
|
|
|
|
David Kentley wrote: To bring it back to the original question, wouldn't re-ordering them in this way at least be a way to see if it fixes his disappearing controls.
No, because the group controls are no longer part of the problem. At this point, all controls are at the same "level." See here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Make sure the dialog window has "Clip Children" set to "False" (Use the Resource Editor to verify)
|
|
|
|
|
That's also set to false.
|
|
|
|
|
Just for grins, remove the "group" controls.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
That also didn't help. I think the problem is far more down in the code, not in the dialog resource. Are the no common code problems that could cause this?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
