All,
I have a C++ COM DLL written using Visual Studio. All the interfaces have GUIDs in idl and rgs files. We want to create a new DLL with brand new GUIDs as we want it to co-exist on the same machine with the old one but with different logic. The number of GUIDs is more than 200. Is there a tool that finds the GUIDs and replaces them ? I noticed for every GUID in idl file there are 3 same ones in the rgs files.
I am not really into C++ COM but I have to get this done :
Rgds,
MK
We use the following dumb but working approach: we store all the GUIDs relevant to COM classes and interfaces as #defines in one header that is included into the .idl file. When we need to break compatibility we just open that file and manually replace all the GUIDs. Not very elegant, but reliable and works.
So my suggestion is that you just search for all the GUIDs in your project and replace them. I guess you'll be better off moving them all in one place at the same time.
Related
I'm trying to create com object using C++ ATL. In add ATL Simple Object wizard I forgot to fill ProgID field. Is it possible to add ProgID later? I found that it is located in *.rgs file. Is it safe to edit this file? If yes, how to deal with UI that are also required in definition syntax in this case?
As I understod ProgID is important when you want to create COM object for example using command CreateObject in VB. What are other methods to create com object with late binding when ProgId is missing?
Yes, it's safe to edit the .rgs file. It's just a registry script - defining where the ProgID is going to be inserted into the registry. (When using C++ in Visual Studio, it seems to me that they don't seem to have as many automatically-generated files that you shouldn't edit. The ones that are generated are usually labelled. (Like the stubs and headers that are generated from .idl files.))
All the wizards are doing is automatically filling in some of the files that you would normally need to do by hand. Knowing what gets put where is really useful, so, if you've already tracked down this bit, it sounds like you're on the right track.
I am a .NET guy who is having to do some work on an MFC app. The app is a VS2008 MFC executable which I have converted to VS2010. The original developers did localisation by specifying the name of a .txt file with key value pairs in it on the applications command line. Installed shortcuts to the executable specify a different .txt file depending on which country the app is being installed in. This of course does not work if you just run the .exe directly. This seems like a weird way to do things to me.
I want to do this the propper MFC way, but I am having difficulty finding definitive answers on Google. My understanding is that the String Table in the .rc file should be used for this localisation? Is this the current best practice for MFC?
With respect to the String Table I have read that the practice is to create multiple string tables each for a different language. How do MFC applications choose which language to use? Is it based on the machines current language settings or can I control this (it may be that we want the language to be specified by the Wix .msi installer we are also building)?
I have also read that embedding all resource inside an MFC application has fallen out of favor and that now you should compile seperate resource .dlls? Is this is true ill investigate how to do it...
Finally, do I have to do something special to get MFC to support Unicode or is MFC Unicode by default?
Thanks
The idea is that all localizable items should be stored in resources. Standard UI objects such as menus and dialogs are automatically stored in there (resources) for you but items such as string literals (eg: error messages, messagebox prompts,...) should be pulled from source code to the string table. This short codeproject article of mine demonstrates how to easily pull strings from the string table in your code.
Note: You should have only one string table in your resource script (.rc).
From there on, you can translate your resources and create resource DLLs (aka satellite DLLs). The idea is that you keep a different copy of the .rc file(s) for each language. Each translation is compiled into a codeless DLL that acts as a container for the resources.
This other codeproject article of mine lets you easily load resource DLLs according to system settings or user preferences: The code looks among your resource DLLs which available language best matches user settings (based on user's UI language and regional settings). The code also lets you easily build a menu with all available languages. That way, your user can override the default choice.
DISCLAIMER: My ad follows. Feel free to skip :-)
Regarding the translation of resources, the management of translations and the creation of resource DLLs, you may want to check out appTranslator.
END OF AD :-)
Regarding Unicode, MFC ships with ANSI and Unicode versions of the code. It's up to you to choose if you want to build an ANSI or a Unicode app: Just make your pick in the first page of project settings. Of course, if you are startgin from scratch, you should definitely go Unicode. But if legacy reasons force you to stay ANSI/MBCS, don't worry to much: It won't prevent you from localizing your app.
Years ago when I had to work with multiple languages in MFC, we used separate resource DLLs. All you need do is make one call to switch which handle the resource functions would use and all was automatic from that point forward.
You need to do more than just change the strings. Dialogs in particular will have strings inside of them, and you may need to change the layout if those strings become too long after translation.
How can I add a new row (with contents) to an existing Excel .xls file using unmanaged C++ running on Windows?
I don't mind using OLE, COM, or any external free library, whatever is the easiest way.
There is a COM interface which is well documented.
I'd suggest you start with the Workbooks.Open method to open an existing excel file.
If you only need basic features (no formatting, formula's, ...), you can also use BasicExcel: A c++ library which doesn't have any dependencies (it reads and writes the excel file as a compound file) and is much easier to use than the COM interface (at least from c++).
I've used SQL to do this. I don't have sample code handy, but a quick google search brought this up: Link
Hope its helpful.
If you have no restrictions to use managed libraries you can check NPOI, a managed library to handle Excel file format.
Since it is managed it should be possible to register it as a COM server. If, for any reason, it proves hard/impossible to register it as a COM server you can write a thin COM server (either in C++ or C# or whatever you prefer) to expose just the functionality you need to your unmanaged C++ code.
I've used this one: ExcelFormatLib, it's great and simple to use, C++, well maintained, compiles and works without any trouble.
For my application (an MMC snap-in) I need to create a single native DLL containing strings that are localized into different languages. In other words, if you were to inspect this DLL with Visual Studio, you would see multiple string tables, each associated with a different locale but containing the same string IDs.
The approach I would like to take is to have various subdirectories under my project directory such as "de", "en", "es", etc (i.e. one for each language). Inside each subdirectory would be a file called "Resources.rc" which would be the RC file containing the strings for that language. Having my resources in this structure would be ideal for the localisation team.
I have managed to create my various RC files and have added them to my Visual C++ project. They all appear correctly in Solution Explorer in Visual Studio (you basically see five instances of an entry called "Resource.rc", but each entry points to a different file).
The problem comes with building my project. It seems that only a single one of the RC files (the one that is specified first in the vcproj file) is compiled into a RES file and included into my DLL. Presumably this is because Visual Studio does not like the fact that the RC files all have the same name.
Is there any way to achieve what I want?
Thanks!
Yes. And No.
If you want multiple RC files you are going to have to leverage off the Operating systems support to have multiple resources in one file. In the resource editor, for each resource, you can set its locale AND the resource editor will allow you to have multiple resources with the same ID, as long as their locale is different.
So, your first step would be to edit each of the RC files to ensure that the resources in one are English/US, another contains French etc.
Next, get the main RC file to #include the others.
Lastly, and this is the problem, you need to rely on the Operating systems logic to load the correct resources. If you are happy to let the locale of the PC determine what UI language is used you have done enough.
If you want to provide a menu option allowing users to change languages: SetThreadLocale used to be an easy way to switch the Locale of loaded resources on the current thread. Since Windows 2000 some unfortunate overloaded usage of the API has caused MS to deprecate its usage in favor of requiring App Developers to always use FindResourceEx - which really doesn't help you if you want, for example, to load a string from a string table.
If you really want an easy way to have a user selectable UI language, then you need to place each of your .rc files into a seperate dll. and then LoadLibrary on the appropriate language resource dll.
I have a schema (xsd), and I want to create xml files that conform to it.
I've found code generators that generate classes which can be loaded from an xml file (CodeSynthesis). But I'm looking to go the other direction.
I want to generate code that will let me build an object which can easily be written out as an xml file. In C++. I might be able to use Java for this, but C++ would be preferable. I'm on solaris, so a VisualStudio plugin won't help me (such as xsd2code).
Is there a code generator that lets me do this?
To close this out: I did wind up using CodeSynthesis. It worked very well, as long as I used a single xsd as its source. Since I actually had two xsds (one imported the other), I had to manually merge them (they did some weird inheritance that needed manual massaging).
But yes, Code Synthesis was the way to go.