|
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. 
|
|
|
|
|
Handle WPARAM and LPARAM for custom messages even if you are not using them to avoid crash in release mode.
|
|
|
|
|
I'm using c++ and I have to make a struct big numbers that can keep numbers up to 10^26. I've done this by using a string with a length of 10^26 but now I have to make a funcion for diving the big number with an integer. Can somebody please help me by giving me an idea how to devide this big number (string) with an integer?
|
|
|
|
|
k_micak wrote: I've done this by using a string with a length of 10^26
WOW, your machine must have inifinite memory resuorces. 
(Just kidding)
IMHO the task is not daunting (you may mimic the 10-based division-by-hand technique learned at school) but it will turn out to be quite inefficient. Why don't you have a look at a library like this one [^].
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
|
|
|
|
|
wow, I really trust a library when :
"GMP is very often miscompiled! We are seeing ever increasing problems with miscompilations of the GMP code. It has now come to the point where a compiler should be assumed to miscompile GMP. Please never use your newly compiled libgmp.a or libgmp.so without first running make check. If it doesn't complete without errors, don't trust the library. Please try another compiler release, or change optimization flags until it works. If you have the skill to isolate the problem, please report it to us if it is a GMP bug; else to the compiler vendor. (The compilers that cause problems are HP's unbundled compilers and GCC, in particular Apple's GCC releases.) É
|
|
|
|
|
Well this sometimes happens on GCC world. At least they are honest. And probably you should never use a library for GCC whoose make check fails.
I'm confident that passed the make check obstacle, nobody will exchange the library with the string-based approach.
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
