|
Blake Miller wrote:
There is not an API to 'get version information' that is called within your modules, so there is nothing you can readily override at runtime.
Maybe I'm not understanding your reply, but isn't that what VerQueryValue(), GetFileVersionInfo(), and UpdateResource() are for?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Could be 
I REALLY believe he wanted to know if there was an API he could intercept or hijack so that when it was called from OUTSIDE his modules, he could return version information that was consistent. At least, that is how I interpeted the original question. Or, put yet another way, 'what function do I export that clients call to get my version information' and the answer to that is "there is not one that is standardized".
Therefore, he should build all his modules with consistent version information, and the easiest way to do that is to make them all include a common file with similar version information. If that is too much trouble, then, yes, a tool that plugs a version information resource into an already built module would suffice. Extra work and effort, but certainly doable.
|
|
|
|
|
This is a total newbie question, and am almost too embarased to ask it, but bear with me...
I created a program in VS.Net 2003 with windows forms, buttons, menus, etc... How to I run this program on other machines without VS.Net or any framework installed? I copied the .exe file from the debug folder, but it won't run on other machines
Any help would be appreciated (and a little newbie bashing will be tolerated)
|
|
|
|
|
Ooder wrote:
How to I run this program on other machines without VS.Net or any framework installed?
You can't. The .Net framework is required on the target machine.
Ooder wrote:
I copied the .exe file from the debug folder, but it won't run on other machines
You must compile the program in Release mode and copy that version to the target machine.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
So any program I create won't work on another computer unless it has the .Net framework installed, even if I compile it in Release mode?
|
|
|
|
|
Yes that is the advantage of .NET - redistributable of 20 MB or so... 
Of course, maybe it will be deployed already with future (maybe XP already has it...) operating systems.
|
|
|
|
|
There are tools out there that allow you to merge the framework with your exe and compile the MSIL to native code...
Strongly not recommended because your exe will not be serviceable (and a raft of other disadvantages). Just install the framework on the machine. period
Alex Korchemniy
|
|
|
|
|
I have not used VS.NET, but it should allow you to staticaly link to the libraries you are using. what that means is that the library becomes part of your program. In the passed that used to mean the entire library, but today it just means the parts that you actualy use. This will make you program much larger, depending on how much of it is linked to your program.
The main advatage of using DLLs, is that you may be sharing the library with other programs. If the creator of the DLL fixes minor errors in the DLL and the user update that same DLL, then the fixes also affect your program.
The disadvatage of using DLLs, is that you must redistibute the DLLs with your program (just incase your users do not have it installed).
As for DEBUG and RELEASE: The problem is exactly the same thing, you have to ether staticaly link the DLL libraries or install the libraries on the target machine. The only reason for installing a DEBUG version on a target machine is that it will give you some feed-back. You can accomplish that in the DEBUG or RELEASE version by setting your own a define statement, instead of using the _DEBUG statement. The advatage of useing the _DEBUG statement is that it will generate the ASSERT dialogbox on the the target machine. The disavantage is that MFC will (some-times) generate an invalid ASSERT dialogbox, meaning that the call will fail but do no damage (if youre handling the result, then no problem).
Sorry, I tend to get carried away.
Good Luck!.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
How do I make the window for my program non-resizable?
|
|
|
|
|
One way is to remove the WS_THICKFRAME style.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
And how exactly would I do that?
|
|
|
|
|
By reading here.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Anonymous wrote:
How do I make the window for my program non-resizable?
In Continuation with Mr Crow, you can also handle WM_GETMINMAXINFO message to do so
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
While that message does affect the frame's size, it does nothing for the cursor which would still indicate that the frame could be sized.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
So which way to go? Pros-n-cons? 
|
|
|
|
|
Hi everyone,
I have a problem concerning the WM_LBUTTONDOWN message.
I'm subclassing a list view control using MFC to implement owner-draw abilities, and I'm using ON_WM_LBUTTONDOWN() in the message map.
BUT: When releasing the left button on the list view control nothing happens, the message handler only gets called when double-clicking the left mouse button...?
Any suggestions?
Alex
Don't try it, just do it! 
|
|
|
|
|
Maybe the WM_LBUTTONDOWD got reflected to the parent of the control?
|
|
|
|
|
Doesn't reflection work the other way 'round? In other words, by default messages go to the control's owner and then reflection reflects them back to the control so that message handling can be done in derived control classes?
|
|
|
|
|
Yes, that is the definition of reflection.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Excuse me. Maybe it was HANDLED by the parent, in which case it will not be reflected back to the control. MFC handler processing code will typically stop at the first handler it finds. If you have a stub handler in your parent window you 'forgot' about, you can scratch your head a long time trying to figure out why the 'reflected' message is never received by the control.
|
|
|
|
|
If you're looking for clicks on the list control, you need to be handling LVN and NM messages such as NM_CLICK
|
|
|
|
|
I just tried this - handling the NM_CLICK message - at both the dialog and control level and it works in both cases.
|
|
|
|
|
Yeah, I will check NM_CLICK.
I've found out why WM_LBUTTONUP can't be received by MFC...
WM_LBUTTONDOWN: Processed in different ways depending on whether a click or drag operation is being initiated. To determine which operation is involved, the list-view control enters a modal message loop until either the button is released or the mouse is moved. (MSDN)
The message is only received if I move the mouse before releasing the button.
Thanks for all your quick answers,
Alex
Don't try it, just do it!
|
|
|
|
|
In that case, you should look into the LVN_BEGINDRAG message, which sounds like what you need.
|
|
|
|
|
By the way, I just looked at some old code of mine and saw that we handled WM_LBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP and LVN_BEGINDRAG. We handled all these messages to have control over changing the mouse cursor to represent what was being moved or in some cases to display a shape that indicated something that could not be dragged. Handling these messages also enabled us to change the cursor to indicate a valid "drop zone".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
