I need to add the support for a number of languages for Win32 GUI application (ATL/WTL).
There are two restrictions:
Project is built using Visual Studio 2010 (no C++11 and also no MFC)
Result must be only ONE standalone *.exe (no additional files/DLLs)
The first and, actually, the only way I found (without DLLs) is to use STRINGTABLE in Resource-file, naming localizable strings like:
WHAT_IS_YOUR_NAME_EN = ...
WHAT_IS_YOUR_NAME_ES = ...
WHAT_IS_YOUR_NAME_DE = ...
etc...
And after, at the Application start, to detect current locale and to load correspondingly post-fixed strings from Resource STRINGTABLE (e.g., "*_DE")
But it looks ugly (no?) and difficult to maintain and to add new languages.
Please, help with alternative advice.
Thank you!
Related
I am facing the following issue:
I have translated my application into different languages using resx files. I want to use the same resx files in other apps as well.
For different apps, I should be able to change the default language (some apps will only be available in Spanish, others only in English, and others multilingual)
I figured I could just name the resources LanguageStrings.es.resx and LanguageStrings.en.resx, and use NeutralResourcesLanguageAttribute to set the default language of the app.
However, when there is no LanguageStrings.resx (invariant file) in the app, the application seems to break (MissingManifestResourceException). I thought the Resource Manager should use the setting in NeutralResourcesLanguageAttribute to find the correct resource (for example; fall back to Spanish) instead of looking for a neutral file.
Is my assumption correct and am I running into a platform bug? I have noticed that ResourceManager.GetNeutralResourcesLanguage doesn't returned the language defined using NeutralResourcesLanguageAttribute, but invariant culture instead
Without a invariant resource file (LanguageStrings.resx), the compiler won't pick it up. You should let the English resource file (Currently LanguageStrings.en.resx) be the invariant file, ie. without .en in the filename, and then set
[assembly: NeutralResourcesLanguage("en")]
All .NET applications work this way. It's not a unique "issue" to Windows Phone.
I believe if you specify your language as supported in the element in your csproj - you need to have the resx that you are trying to use in the supported culture. If you use the language that is supposedly supported and the resx is not there - you will get a MissingManifestResourceException. Neutral language will be picked up if the current language is not supported.
A word or two about project I have to make.
I have a list of products (XML formatted), and I have to make a bar code of that list.
Here are the requirements:
Technology has to be MFC, VS 2005 or VS2008
All functionality must be in one dll
Same solution should have a simple tester for the dll
I will use pdf417. http://en.wikipedia.org/wiki/PDF417 http://sourceforge.net/projects/pdf417lib/
Also, I would like to provide an interface, so that different bar codes can be implemented in future.
For example, my dll has "Write" method which is implemented in a separate file for pdf417 and in a separate file for some other bar code, so that user can choose which bar code to use.
Since I have no knowledge of mfc, I really don't know how to even start. I read some tutorials, created the dll with some dummy method, and then tried to use it in tester application, but no luck.
I know that this is a "needle in a haystack" type of a question, but if someone could help me how to setup/architect this project I would be very grateful.
Thanks,
Marko
I don't see how you benefit from using MFC if your DLL's client is not an MFC app. You are better off using a standard C interface in your exported functions if you want to support non-MFC clients. Just create a Win32 project and choose the project type as DLL, then the wizard will generate some example exported function for you. Follow the examples to create your own export functions.
Visual Studio seems to want to put class contructor code and event handling code in the .h file. I have only been involved in small 1 man projects and was wondering what the general industry standard was.
For Visual C++ Application projects what code would one put in the .h file? I am used to the mode classical C++ way of declaring your class in the .h file and coding in the .cpp file. Does this still apply to Visual Studio applications?
I have a strong C background which would explain my preference for this. The VSC++ compiler doesn't seem to mind.
In short: What is one supposed to put in which type of file?
TIA
Ends
There is no widely accepted industry standard. By putting (short) function definitions in the header, you give the compiler a better chance to inline the code. The benefit is that it can make the code run faster (keep those functions short, though). However, this comes at the cost of exposing more code to the clients who include that header, making you (or your colleagues) recompile more files when you change the implementation.
You also have to take into account the cost of going against your tools. Since VC++'s wizards insist on putting the functions in the headers, you have to move them everytime if you disagree.
It's really project-specific, I would say.
If you're using MFC and you're talking about the generated code, it's best to leave it alone.
If you're trying to do 'normal' C++ development, put as little as you can get away with in the header, as it means client code doesn't depend on too many implementation details. What you can get away with depends a little on use of templates, and how much indirection your performance budget can support.
For Visual C++ Application projects
what code would one put in the .h
file? I am used to the mode classical
C++ way of declaring your class in the
.h file and coding in the .cpp file.
Does this still apply to Visual Studio
applications?
Short: Yes
Long: Depends on the person or language. In c++ the header is for declaring and cpp for the coding. For C# you have one file (or if you use interfaces, 2)
This might seem minor, but just remember: headers are #included in several places. (And headers including headers complicates things further.) Any time you change a header, a lot of files are gonna be compiled again. Keeping as little of frequently changing code in the header reduces recompilation of dependant files.
Another thing: an uncluttered header file gives you a quick overview of what a class/form has to offer.
Last year I wrote a Language Service for Visual Studio which added syntax highlighting for NHaml files: http://github.com/snappycode/hamleditor.
To clarify, NHaml is a html template language that can mix in code elements like an aspx file can. This plugin adds support to the IDE for editing NHaml files, but basically only adds syntax highlighting.
I was wondering if anyone knows how to add inline c# intellisense to the service like you get now in an aspx file. I'm hoping that would be possible without doing the whole c# grammar myself specific for the plugin.
Has anyone written a language service that mixes languages?
UPDATE:
It looks like the spark view engine guys have made some inroads here, I am investigating their implementation
I checked the Spark View Engine, and they seem to have made a generic ATL stuff (called SparkLanguagePackageLib), that in fact seems to be not containiag anything Spark specific. It seems to be just a generic C# intellisense library that needs the following:
The original code
The C# source that gets generated from the original code
The position mappings between the two (for example the code on line 2 pos 5 gets mapped in the output to line 4 pos 10, etc.)
Some other things, like Paintings(?)
And after that you can call:
events.OnGenerated(
primaryText, // original source code
entry.SourceCode, // generated sourcecode
cMappings, // mappings between the two
ref mappings[0], // ?
cPaints, // ?
ref paints[0]); // ?
I've tried to find Spark-specific stuff in that C++ library, but I couldn't find anything: everythig spark-related is split to a separate C# code file. I think this is good, because:
You don't need to edit the C++ files
If the spark view engine's intellisense support is installed it can be used by other view engines too
You only need to create a class, that maps between the original nhaml file and it's generated C# counterpart.
Btw. Are you still working on this NHaml Intellisense library? If not I'll try to patch their implementation in hope it can be converted to NHaml easily.
this looks like it might help
http://www.codeproject.com/KB/recipes/VSLanguageService.aspx
I finally managed to modify the code to support NHaml. It wasn't that hard at all. Unfortunately the original NHaml library doesn't support everything that was needed, so I had to create a new parser for NHaml. It doesn't support all of the constructs, but it supports most of them (enough to make NHaml programming easier)
Download: http://github.com/sztupy/nhamlsense
Screencast: http://www.youtube.com/watch?v=8jTZ2zC9eYc
You can easily add keywords by creating or modifying a usertype.dat file. Check here for some directions on attaching to specific file extentions. That might get you at least part of the way, without redoing the complete c# syntax.
(In fact, I'm not sure what you mean exactly by 'syntax highlighting' in this context. I'm sure, for instance, you get brace-match highlighting for free in the editor).
Whats the easiest way to find out what programming language an application was written in?
I would like to know if its vb or c++ or delphi or .net etc from the program exe file.
Try PEiD
of course if they used a packer, some unpacking will need to be done first :)
Start it up and check what run-time DLLs it uses with Process Explorer.
If that doesn't make it immediately obvious, search the web for references to those DLLs.
Most disassemblers (including Olly I think) can easily show you the text contained in an EXE or DLL, and that can also sometimes give a clue. Delphi types are often prefixed with T as in TMyClass.
If it's a small executable with no DLL references and no text you might be SOL. At that point you'd need to look for idioms of particular compilers, and it would be mostly guesswork.
There is an art to detecting what language a program was written in. It is possible but there are no hard and fast rules. It takes a lot of experience (and it also leads to the question "Why would you want to..." but here are a few ideas on how to go about it.
What you're looking for is a "signature". The signature could be a certain string that is included by the compiler, a reference to an API that is quite common in the programming tool being used, or even a style of programing that is common to the tools being used, visible in the strings contained in the application.
In addition, there are styles to how an application is deployed: various configuration files found in the deployment directory, dlls and assemblies and even images, directories or icons.
Java applications wrapped in a self-launching executable will contain references to java libs, and will likely have certain libraries or files included in the same directory that indicate that it's java.
As indicated in other answers a managed assembly will show certain signs as well: you can open it in Reflector etc. While it is correct that c# and VB are "interchangable" once compiled, it is not true that they are identical. If you use Reflector to disassemble VB code you will quite often see that the assembly references the Microsoft.VisualBasic.dll assembly. You'll be able to tell the difference between Mono applications because they will most likely contain references to the mono assemblies.
Many compilers assemble and link code in certain ways, and leave footprints behind. For example, examining a window executable using "strings: tab in Process Explorer, you'll see a lot of strings. Using these you may be able to determine programming styles, methods called, error or trace methods withint the exe.
An example is that compilers use different mechanisms for localization: Microsoft stores localized strings in XML files or resource files. Other compilers will use a different tactic.
Another example is c++ name mangling. The CodeWarrior compiler uses a different algorithm to mangle the names of the member variables and functions of a call than Visual Studio.
I suppose you could write a book on the subject of accurately determining the lineage of any executable. This subject would probably be called "programming archeology".
You could try using Depends to see what runtime dependancies it has, which might give some clues.
The easiest way is to ask the developer of the program. It does not require any knowledge and utility programs.
Determine Delphi Application
Use eda_preview270.exe (from here) or some other spy tool and check the window class names. If they read like TButton or TfrmBlubb, it's a VCL app. If there is an "Afx" in them, it's probably MFC.
Compiled languages (by this I mean no scripting languages, or Java, .NET, etc.) are compiled into CPU assembly instructions, which is essentially a one-way conversion. It is not usually possible to determine which language a program was written in. However, using a dependency walker, you could potentially determine which runtime library the program was loading (if any) and therefore determine which language it used (e.g. MS Visual C++ 9 uses msvcr90.dll).
you can check is that a .net assembly or not by trying to open with ildasm.exe tool
PE Detective works best for me.
In general, you can't.
If you can load it into Reflector, you know it is a managed assembly.
That's a good question. There isn't any general way to tell, but I bet most compilers and libraries leave a mark in the resulting EXE file. If you wanted to spend a lot of time on it, you could gather a bunch of EXEs written in known languages and scan for common strings. I would image you'd find some.
Dependancy Walker, which someone else mentioned would be a good way to look for telltale dependencies, like versions of MSVCRT, etc
i'd try running the .exe thru a 'strings' program to get assorted hints.
If I remember correctly PE Explorer Disassembler gives some information about compiler that creates given not .net and java binary, for .net use Reflector or ILDAsm tool
The easiest way that I found (at least in computer games) was to look in the "redist" folder nested within the game's main folder. It might be obvious to some of you that are more experienced in programming yourself, but the specific purpose of the MSI in this folder is to allow the setup.exe file to automatically install the prerequisites for the game itself.
For example:
In Empire Total War, there is an MSI called "vcredist_x86-sp1.exe". This indicates that the game/program was written in Microsoft's "Visual C 2005" in the .NET Framework (usually).
In fact, if you open the MSI/EXE, the installer should immediately indicate the language it's written in and which version.
The reason I'm familiar is because I code in C# and VB in the .NET Framework and we auto-install the prerequisites for our business app.
Hope this helps!