|
I'm using Visual Studio 2003 for an MFC project, and every once and a while (more frequently lately) some of my menu IDs convert from the ID representation (e.g. "ID_FILE_HELLO_WORLD" to the number (e.g. "20412").
Has anyone else seen this bug, and if so, how can I avoid it? It's driving me nuts!
Warren
(sorry, I also posted this in the C++/CLI board by accident)
|
|
|
|
|
Have you checked your resource.h file to check if the resource ID's #defines are still there? I've never come across this problem...
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Yes, they are okay (and it still compiles fine), it's just when you go into the menu editor all of the ID_... entries are converted to their numbers. It's VERY frustrating!
Count yourself lucky if you don't experience this...
Warren
|
|
|
|
|
This is a well known VS 2003 bug. Annoying huh? It appears to have been fixed in VS 2005.
|
|
|
|
|
Yes it's REALLY annoying. It started out as just a few of my menu items, and now it's "spreading" to quite a few of them! (this is the sort of thing that makes me jealous of those open-source projects - I honestly would spend the time to fix this myself, it would probably be less work than continually repairing my menus)
Is there no work-around? (other than VS 2005)
Warren
|
|
|
|
|
I don't know of any workarounds unfortunately. 
|
|
|
|
|
I found this submitted as bug ID: FDBK17799 at Microsoft.
The final (and not so helpful comment) was:
============================
Resolved as Won't Fix by Microsoft on 2005-07-27 at 12:31:15
Thank you for reporting this issue. We've been reproduced the bug for Resource IDs >= 32768. Unless you are using that many IDs we suggest to use Resource IDs < 32768. Sorry for the inconvinience.
===========================
(which conflicts with the ID-range advice from:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_mfcnotes_tn020.asp
but maybe for the time being, I will change my IDs to this lower range, and take my chances down there 
Warren
|
|
|
|
|
I've already posted this question in the XML forum but i got no answer and i think it's more related to programming than XML.
I have hundreds of structs and enums which describe the data in an ECU (engine control unit), fuel map etc.
The headers with thousands of lines are currently written in C and are used for the embedded system and also in the MFC project on the PC side to edit the tables and to communicate with the ECU.
With Microsofts new .net strategy that won't work well anymore because the embedded and desktop world devides in my eyes.
So what i would like to do now is describe the structs in XML and then create headers for C/C#/... from it. Does a common XML and XSLT file for this taks exist? Any examples? Maybe even an interface editor?
Thanks
Andre
|
|
|
|
|
Of course xsl can do it, but u will have to render it into .h files in a pre-compile step.
macros will take less time to write and pre-compile without a hustle.
|
|
|
|
|
The structs don't change anymore, but in cases where they does a pre-compile step could be added to the project.
I would like to see how others have made it before i custom make it, how unions are described and how i can add language specific attributes to the structs.
C++/CLI / C# expects additional keywords like value/ref/public...
|
|
|
|
|
Why won't it work any more? You can use C headers in C++ under .NET
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
That's correct, but you can't use C headers in the managed world. As mentioned C++/CLI expects additional keywords.
|
|
|
|
|
ABuenger wrote:
That's correct, but you can't use C headers in the managed world. As mentioned C++/CLI expects additional keywords.
It accepts additional keywords (ref, value etc...) but does not expect them - they are not required. If you don't use them, it specifies standard unmanaged types. I have used header files of structures from VC6 completely unmodified in VS2005 without any issues, including unions, structs and enums.
Of course, there may be specific reasons why your header file doesn't work. Have you tried it?
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I need to internationalize an application i am developing which UI is currently in english. I thought about putting the strings in a table in a SQL database (Sqlite) and then query the strings at runtime.
Are there better options? I don't like multiple string tables in the resources or a resource DLL. I would like to be able to edit the strings side by side where a sql database is the option in my eyes.
Any pros and cons? Examples?
Thanks Andre
|
|
|
|
|
There are many ways to handle the problem. Your way should work as well as any other. I like to use an ini file for my UI strings as it is an easily editable text file.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
Do you have all string in one file or one file for each language? The big advantage of a table in a database would be that during development i can just append the strings in english and later i can fill the empty cells with translations.
Would you use an integer or string as primary key of the table? An integer (auto increment id) would have the disadvantage that i also need an enum with the ids.
I thought about something like this:
CString sString = QueryString ("ID_FILE");
|
|
|
|
|
ABuenger wrote: Do you have all string in one file or one file for each language? The big advantage of a table in a database would be that during development i can just append the strings in english and later i can fill the empty cells with translations.
One language per file.
Actually I currently have only English files, but it is simply a matter of making a copy of the file, translating it, and distributing the translated ini file with the app. Or distributing all the language files and having the installer rename the correct one for the language used. Using this method also makes it easier for me (or anyone else) to correct any spelling mistakes or ambiguities that I may have missed when writing the app without having to recompile.
One thing I did do though is put all the default strings into the app's string table in English just in case the ini file can not be found or is corrupted some how.
ABuenger wrote: Would you use an integer or string as primary key of the table? An integer (auto increment id) would have the disadvantage that i also need an enum with the ids.
I thought about something like this:
CString sString = QueryString ("ID_FILE");
That would be my prefered method. Makes it easier to associate strings with controls, menu items, etc. if they all have the same ID strings. Numbers just are not descriptive enough.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
Would this technique perform well at runtime? Unless you had some sort of caching the performance would be considerably slower then LoadString. Even with caching you would have an initial delay while the cache is primed.
Steve
|
|
|
|
|
I don't think that there will be a performance penality even if the strings are queried on the fly. Also they could be cached in a map or array.
|
|
|
|
|
In your particular app it may not be noticeable - But I'd be willing to bet it would be slower. LoadString is a simple API optimized for the simple lookup of strings which are already in memory and SQLLite is a fully fledged database engine. In general generality always has its price. I would suggest that you make a simple app to measure and see - Nothing fancy, just load some strings in a loop and time it.
Steve
|
|
|
|
|
I think we are talking about hundreds or tenth of a second. A sql database would have the advantage that with a simple script the strings could be exported to .c files with static arrays of strings and compiled into the app.
|
|
|
|
|
A tenth of a second is a lot for a computer. You are correct in that if you have a database you have more flexibility - Such as in your example - With this technique I guess you could have the best of both worlds by compiling the strings (from the database) directly into the app via the exported C file. Still to me it seems an overly complex solution to a simple problem - although you may have compelling reason to use a database I don't know about.
Steve
|
|
|
|
|
I don't think a user would notice if the creation of a window or dialog takes a tenth of a second longer.
My problem is that i need the strings in a MFC project as well as in an embedded system (handheld controller) with very limited memory resources. With string tables in the resources i am bound to MFC. Also in most cases i have seen yet the string tables are missing more or less strings over the time because it is a hard task to keep them all up to date.
So the options i see for me is either a sql database, XML file or some other kind of text file.
In my eyes a table is less error prone because i have the columns for each language side by side and can easily find empty cells. I could even query for empty cells to find out if i have missed some.
|
|
|
|
|
If you want to generate a text file form the database (a .C file with the strings in it) perhaps XML would be a good choice, you could use XSL to do the conversion. I imagine by now with all the hype around XML there a plenty of good editors around.
Steve
|
|
|
|
|
It will be slower, but we are talking about UI strings here. Most UI elements have very few strings so the impact will be the UI loading a few milliseconds slower. I doubt a user would ever notice the difference.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
