|
 The normal expectation would be that running the Release build from within VS and running the Release build on a computer with VS installed are the same thing. You could always try the catchall solution of turning off incremental linking in your project settings and doing a full rebuild. The CRT environment is what's keeling over but that is essentially just a statically linked library or an implicitly linked Dll depending on your project settings ( Make sure if you have multiple modules that the CRT settings are consistent throughout ) Beyond that it's not to easy to get the old veteran that is MSVCRT.DLL to fail in such an arbitrary manner.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Can anybody tell me how I can realize a certain computer?
I mean maybe it's possible to define an unique code for any computer.
|
|
|
|
|
what are you trying to do ?
I really don't understand your question.
|
|
|
|
|
|
Usef Marzbani wrote: I mean maybe it's possible to define an unique code for any computer.
I do not think that you will be able to generate a guaranteed unique value for ANY computer. You might be able to get a "good enough" identifier by looking at a system's hardware and software.
For example, if you want to lock a software application to a certain system, you could look at things that are less likely to change, like:
o Geometry of the Windows System drive
o CPU Serial Number (if supported by the CPU)
o First NIC's hardware address
o results of the CPUID instruction
o Installed Memory
Choosing a value that changes easily, like number of hard drives or drive letters, swap file size, etc., is a sure-fire way to piss off your users if they have to re-validate their license each time this happens.
Peace!
-=- James Please rate this message - let me know if I helped or not!<hr></hr>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Hi,
Is it possible to embed VERSIONINFO informations in a c# project ?
I tried integrating the .rc file in my project, and modified the generation action to 'embedded resource' but the binary still show the assembly version 
|
|
|
|
|
There is a specific forum for C++/CLI .NET questions and this is not it. Have look at the forum titles.
I have not tried to import an existing RC file but if you create a new C++ managed winforms project it has an RC file which you can add a VersionInfo section into so it is supported some way.
VS2005 on XP Pro
|
|
|
|
|
oh sorry, I was confused where to put this question, so I posted it twice 
yes, you are right! this work in a manged c++ porject, but that's not what I need, I already invested more than 3 months in c# and I am not ready to move to c++ just for this 
|
|
|
|
|
So you are doing C# development? Don't take this the wrong way but in the 44 minutes since your first post I could have have easily manually copied the Version Information values from a RC file into the Version information of the AssemblyInfo.cs file.
|
|
|
|
|
I am sure you can do that 
In my case, I am using a shared version.rc file generated on the fly by the server doing the compilation.. this is getting a little more complicated 
|
|
|
|
|
|
Thanks mike, I appreciate it
|
|
|
|
|
Hi all,
I am writing a program that has a main window with a list control. Upon double clicking an item in the list control, I open a dialog box pertaining to this item (There are a numebr og dialogs in a linked list, of which one is selected). The dialog box is running in a modeless mode, since processing in the main window must continue. When I press the OK button, I send a message to the parent window (I pass the m_hWnd of the main window to the dialog boxes and use ::PostMessage) This message causes the main window to update the list control to reflect possible changes made in the dialog box. I then call "DestroyWindow" for the dialog.
This works fine the first time, but it crashes the second time I enter the same modeless dialog. When I comment-out the postmessage call, then everything works fine, so it seems that this message causes the crash. I can see that it is processed before the crash.
Anyone any suggestions?
Thanks in advance,
William
|
|
|
|
|
Did you use your debugger to pinpoint the exact problem ? This will bring you much more information that we can give you from your post.
|
|
|
|
|
I tried to, but the problem does not occur in the debug version of the program....
William
|
|
|
|
|
William Engberts wrote: but the problem does not occur in the debug version of the program....
The above is a kind invitation to visit [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
I would doubt that the PostMessage itself is the culprit - but the handler in your main window for the message might be.
The other thing to be careful of is that you aren't using the HWND value from the first incarnation of the modeless dialog after it is no longer valid.
Rather than ending the modeless-dialog, you could simply keep it in existence the who time, and just ShowWindow (SW_HIDE /SW_FALSE) it?
Obviosuly what the crash is will have a lot of information for you. You have debugged it and seen how it crashes, haven't you?
Iain.
Iain Clarke appears because CPallini still cares.
|
|
|
|
|
Iain,
Thanks for your remarks. I do not think that the postmessage is the problem either, since I see the results of processing the message which has obviously been sent and processed. The crash occurs somwhere later.
I do not use the HWND of the modeless dialog box at all. I use the HWND of the parent dialog, which remains active all the time. This is the window that has to process the message (write changes to a file and update the list control).
I tried to keep the modeless dialog box in existence (using ShowWindow (SW_HIDE) rather than DestroyWindow. I still send the message before hiding the window, with exactly the same result: BANGGG!!
I did try to debug the darned thing, but then it behaves like an angel. No crashes, however often I enter and destro the subwindows.....
I also found out that it does not matter if I enter the same modeless dialog box twice, or if I enter one and then another. The second OK will make the system crash (in the release version)
William
|
|
|
|
|
Thanks all for your replies. I think I found the problem. There was an issue with the prototype of the message handler function. When I corrected this, the problem had disappeared.
Regards,
William
|
|
|
|
|
You're not allowed to fix the problem yourself! I just read your message in my email, and went "aha! this sounds exactly like the problem I had 9 years ago, with MFC blindly casting the prototype..."
This ended up with stack corruption, and a crash that was very difficult to pin down. And didn't show up in debug mode with its extra padding.
Now you've ruined my chance to show off through your self reliance!
Curses,
Iain.
Iain Clarke appears because CPallini still cares.
|
|
|
|
|
I deeply and humbly apologize. I hope you can forgive my inexcusable violation of this esteemed forum's practices. I have already put ashes on my head and will refrain from all pleasures of the flesh for the coming week or so........
Greetings,
William
|
|
|
|
|
William Engberts wrote: will refrain from all pleasures of the flesh for the coming week or so
Whoah there! I grant you an indulgence to eat as much chocolate as you like this easter weekend. I don't mind if you're not from a christian heritage country or not - it's still a good excuse.
/forgive,
Iain.
Iain Clarke appears because CPallini still cares.
|
|
|
|
|
he he he nice quote
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/codeProject$$>
|
|
|
|
|
Perhaps you don't really want to "destroy" the children windows if you are going to use them more than once. Better solution might be to create all child windows once (upon start up of main window) and intialize them hidden. Then when you need them you can just hide and show them - this would eliminate unnecessary memory allocation/de-allocation. If you need to reset each child window, you could just call that before the ShowWindow( SW_SHOW ).
Just a thought. 
|
|
|
|
|
Eh, just kidding, just found the rest of this discussion. Not only did someone else already suggest that, but you already solved it. Ok, I'm going to get some coffee now. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
