We have added the Portuguese language to our app. We use this built-in MFC dialog, CMFCWindowsManagerDialog
Until now it hasn't been a problem because these languages
l.chs l.cht l.deu l.esn l.fra l.ita l.jpn l.kor l.rus
are automatically supported, but that's it, there's no Portuguese. I understand that creating a satellite resource DLL is probably the answer. I'm not familiar with that term, but we have resource DLLS for each project in each language, so I assume those are "satellite DLLs", and I know how to make them. But I don't understand how to do it with this built-in dialog. We have to localize CMFCToolBarsCustomizeDialog also, but I don't know where to begin. Any help would be greatly appreciated.
I use appTranslator to maintain all my satellite DLL files and it automatically manages this for you. Sadly it is no longer available commercially.
There are other bespoke localisation software packages out there though (like Lingobit) that also manages MFC translations in a nice GUI environment.
It does all revolve around Resource Only DLL files and this article on CodeProject explains how to make a resource only DLL.
I have an MDI application which uses appTranslator and it does have the window you refer to:
In Visual Studio, if you right-click your resource file in the Resource View and select Resource Includes:
You will be presented with a dialog. In my case:
Notice the inclusion of the afxribbon.rc resource? This contains the dialog in question. Here is my complete inclusion code for reference:
#define _AFX_NO_OLE_RESOURCES
#define _AFX_NO_TRACKER_RESOURCES
#define _AFX_NO_PROPERTY_RESOURCES
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
#ifdef _WIN32
LANGUAGE 9, 1
#pragma code_page(1252)
#endif //_WIN32
#include "res\CommunityTalks.rc2" // non-Microsoft Visual C++ edited resources
#include "afxres.rc" // Standard components
#include "afxprint.rc" // printing/print preview resources
#include "indicate.rc"
#include "prompts.rc"
#endif
#if !defined(_AFXDLL)
#include "afxribbon.rc" // MFC ribbon and control bar resources
#endif
The trick is to add the required AFX system resource into your application. Then it will be exposed for appTranslator and / or Lingobit to translate.
Related
I have a method that verifies a password in a .dll and it should return an error code on failure. It has the following prototype:
#define DllExport __declspec( dllexport )
extern "C" DllExport UINT TestPassword(MSIHANDLE hInstall);
I expect that when this method returns an error code (like ERROR_INSTALL_USEREXIT = 1602) the whole installation process will terminate (no other custom action following this one will be executed), but it doesn't.
Also, in Wix I have the following fragment:
<CustomAction Id='TestPassword' BinaryKey='TestPassword' DllEntry='TestPassword' Execute='immediate'
Return='check'/>
<Binary Id='TestPassword' SourceFile='DummyDll.dll'/>
Quick Link: Managed Code Custom Actions (below is for C++ native custom actions).
UPDATE: Some helpful links.
Hello WiX (minimal WiX Visual Studio Project). WiX quick start suggestions.
Debugging Custom Actions (for native code / C++ just attach debugger to msiexec.exe).
Microsoft Debugging Environments.
Dynamic Link Libraries.
Suspected causes:
Listing some suggestions at the top here.
1) Wrong C++ custom action code configuration, often forgetting to create a CA.def file to define dll exports. I also always use __stdcall (MSI is an old girl).
2) Wrong path to custom action dll in WiX markup (not valid dll in MSI).
3) Forgot to enable checking of error codes in the WiX markup (*.WXS) and then a CA does not end the setup. This looks correct in your case (Return='check').
4) Forgot to insert custom action in installation sequence.
There are a few more, can't think of them at the moment. Might add later... One that comes to mind is bitness problems (x86/64)...
File and runtime dependencies is a classic fallover cause.
Try to statically link whatever you can.
Deployment DLLs should be minimum dependencies for sure since they need to run on any system, in any language, in any state, in any OS version, et...
One of the few cases where static linking is really recommended and always the right choice.
Heads-Up: Avoid Licensing In Setup? I would recommend you put the license validation in your application instead of your setup. Here
are some thoughts on the matter:
Installer with Online Registration for Windows Application (recommended read).
Technical Issues:
FileName.def: I am no C++ expert, but do you have a FileName.def file in your project to declare the exported functions for the dll? If not - add one (steps / procedure below). Make sure it is in the right format (add via Visual Studio, I think it is UTF8 without BOM). Compile and check with Dependency Walker if all exports are correct:
Verify MSI File DLL: You should check the compiled MSI to verify it has the correct DLL inside it with the correct exports available. Hence; verify that the DLL has safely made it into the Binary table of the MSI:
Open your compiled MSI with Orca (or equivalent).
Binary table, double click the Data column for your DLL entry.
Select "Write binary to filename" and save to desktop (or somewhere else).
Use Dependency Walker (depends.exe) to verify that you have a valid DLL as illustrated in the image above. Common problem is that you see no exports at all (MyImmediateCA, MyTestFail, MyTestSuccess, etc...).
Verify the file- and product versions as well in file properties.
Error Processing: A custom action can be set to suppress errors. Your markup looks correct with the "Return attribute" set: (Return='check'). Your snippet:
<CustomAction Id='TestPassword' BinaryKey='TestPassword'
DllEntry='TestPassword' Execute='immediate' Return='check'/>
Sequencing: Also check that your sequencing is OK. Altogether you need to point to the binary table DLL, declare the custom action and then also insert it into the right sequence. Mock-up WiX markup:
<!--<Binary Id="CustomActions" SourceFile="$(var.TestDll.TargetPath)" />-->
<Binary Id="CustomActions" SourceFile="C:\TestDll.dll" />
<CustomAction Id="MyTestFail" BinaryKey="CustomActions" DllEntry="MyTestFail"/>
<CustomAction Id="MyTestSuccess" BinaryKey="CustomActions" DllEntry="MyTestSuccess"/>
<InstallExecuteSequence>
<Custom Action="MyTestSuccess" After="CostFinalize" />
<Custom Action="MyTestFail" After="MyTestSuccess" />
</InstallExecuteSequence>
C++ DLL: And the actual C++ DLL itself (remember the *.def file). Snippet in the bottom code segment from MSI API Custom Action Security:
Suggested steps for Visual Studio 2017:
Create new VC+ DLL Project - Dynamic-Link Library (DLL).
Dump the below code in the main *.cpp file (I avoid the dllmain.cpp).
Add the *.def file!
Right Click Source Files => Add => New Item... => Code => Module-Definition File (.def) => Any name should do... (only one def file allowed)
Add your export function names:
Mock-up:
LIBRARY
EXPORTS
MyTestFail
MyTestSuccess
MyImmediateCA
Close and re-open file to verify if there are any format errors. Select fix if a warning appears. UTF8 without BOM required I think.
#include "stdafx.h"
#include <windows.h>
#include <Msiquery.h>
#pragma comment(lib, "msi.lib")
UINT __stdcall MyTestFail(MSIHANDLE hInstall)
{
MessageBox(NULL, L"MyTestFail", L"MyTestFail", MB_OK);
return ERROR_INSTALL_FAILURE;
}
UINT __stdcall MyTestSuccess(MSIHANDLE hInstall)
{
MessageBox(NULL, L"MyTestSuccess", L"MyTestSuccess", MB_OK);
return ERROR_SUCCESS;
}
// I will leave in the below snippet from the MSI API - section "Custom Action Security". Above two test methods will do though...
UINT __stdcall MyImmediateCA(MSIHANDLE hInstall)
{
MessageBox(NULL, L"Test", L"Test", MB_OK);
// set up information for deferred custom action called MyDeferredCA
const TCHAR szValue[] = TEXT("data");
UINT uiStat = ERROR_INSTALL_FAILURE;
if (ERROR_SUCCESS == MsiSetProperty(hInstall, TEXT("MyDeferredCA"), szValue))
{
uiStat = MsiDoAction(hInstall, TEXT("MyDeferredCA"));
// clear CustomActionData property
if (ERROR_SUCCESS != MsiSetProperty(hInstall, TEXT("MyDeferredCA"), TEXT("")))
return ERROR_INSTALL_FAILURE;
}
return (uiStat == ERROR_SUCCESS) ? uiStat : ERROR_INSTALL_FAILURE;
}
Another answer on MsiGetProperty (retrieving property values). This is a little more complicated in C++ - with the buffers and all. Scroll down for source code.
Minimal Dependencies: In order to minimize dependencies you should eliminate the Visual C / C++ Runtime dependencies and any MFC
dependencies (don't use MFC if you can help it for file size and
performance reasons). If you use MFC, set it to use static linking -
also for ATL. And finally for the C/C++ runtime, see here:
Visual Studio 2010 MSVCR dependency removal?
(there are better links, but all I could find that I have time for
right now - just want to get this in there so it is not forgotten).
The Release mode C++ binary should now not depend on any MSVC runtime dlls:
Here is a screenshot of how the DLL depends on MSVC runtime dlls without this tweak - don't mind the red icons - this is the ancient dependency walker tool which is not updated for modern dependencies, but shows older-style dependencies perfectly:
Please note that debug-mode DLLs may depend on different files than the Release mode binaries. The Release mode binaries are the ones that are important. Obviously never distribute debug-mode binaries!
Error Presented: #include errors detected. Please update your includePath. IntelliSense features for this translation unit(/Users/x/Documents/Arduino/generated_examples/GetStarted_3/GetStarted.ino)will be provided by the Tag Parser.
For example, the following files are not found:
#include "AZ3166WiFi.h"
#include "AzureIotHub.h"
#include "DevKitMQTTClient.h"
What have I done:
Arduino is installed (and runs), Arduino is added to the path as /Applications in the UserSettings.pref. DevKit was installed, pretty much everything works, except this intellisense/libraries location problem.
Actually this is an issue coming from the Microsoft C/C++ extension.
Here is the solution to fix this issue:
Press F1 and key in 'settings' and select the Preferences: Open User Settings
then add this setting to your user settings
Press F1 and key in 'cpp' and select the C/Cpp: Edit Configurations...
this will open / create the c_cpp_properties.json file, add the path of Arduino package into the include path:
You can get more detail from C/C++ for VS Code.
Although it might seems to work better with Tag Parser, I believe it's not the solution, and actually it should default to Tag Parser.
Comments in Default Settings, C/C++ section say:
// Controls the IntelliSense provider. "Tag Parser" provides "fuzzy"
results that are not context-aware. "Default" provides context-aware
results and is in preview mode - member list, hover tooltips, and
error squiggles are currently implemented. Features not yet
implemented in the new default engine will use the tag parser engine
instead. "C_Cpp.intelliSenseEngine": "Default",
// Controls whether the IntelliSense engine will automatically
switch to the Tag Parser for translation units containing #include
errors. "C_Cpp.intelliSenseEngineFallback": "Enabled",
I'm having an issue with the visibility of header files in my Windows Forms project (Visual Studio 2017). I've included all header files in separate header file called "Header.h". In the first file called "welcome.h", I want to call the next form as shown below...
beta::initial^ f = gcnew beta::initial();
this->Hide();
f->Show();
This is what I'm getting when I'm trying to compile it...
That doesn't actually makes sense to me since initial is the member of beta as shown in this screenshot...
This is how I include my header files in Header.h...
#include <algorithm>
#include "initial.h"
#include "welcome.h"
Every other header file contains...
#include "Header.h"
I also checked if every file is sure to be included in the project and everything is in the same folder. What am I missing?
P.S. This is my first time posting here, so if my question isn't clear, then please guide me.
I just put an answer here:
Style messed up after nuget update.
I'm going to create a mail plugin for the OS X Mail.app application for some additional features.
I have no idea where to start as there is no official documentation for plugins.
Can anyone please help me, how can I start the project.
Is there any initial link or tutorial, please suggest?
As noted, writing Apple Mail plugins is not straightforward, since it only has a private plugin API, which is entirely undocumented and can change with any new version of Mail.app. The best code example is GPGMail, which is open source & still active (already working on Yosemite support). Here is what I successfully did to get started (will put it up on github once finished):
How to build a minimal Apple Mail plugin (as of Mavericks & Xcode 6.0.1)
you need to create an OSX "Bundle" project in XCode
wrapper extension is mailbundle (under Packaging in the project Build settings)
a bundle needs to be stored under ~/Library/Mail/Bundles (as Build Phase add a Copy Files action with that as absolute path destination and the *.mailbundle from your build/ folder as item to copy)
for development, I have set up /Applications/Mail.app as executable in my run scheme, so that Run in XCode will build it, copy the bundle and start mail; note that at this point you'll get an error from Mail that your plugin cannot be started and was disabled
you need to provide a list of SupportedPluginCompatibilityUUIDs in the Info.plist, I stole it from GPGMail, these change with new Mail/OSX versions
use class-dump to generate the header files from Mail.app's private API
starting point is MVMailBundle, which you have to inherit from and which has a registerBundle method to hook you in
I extracted that from the huge generated header file in a small MVMailBundle.h header to include where needed (as done by GPGMail)
create a new class MyMailBundle, inheriting from NSObject
it needs an initialize method
and set it as "Principle class" in the Info.plist so that it gets run when the bundle is loaded by Mail.app
#import <Cocoa/Cocoa.h>
#interface MyMailBundle : NSObject
+ (void)initialize;
#end
initialize implementation: previously, you could use the simple way and directly inherit as done in Letterbox, however, since 64-bit runtimes of Objective-C you have to use the dynamic way as done by GPGMail:
using NSClassFromString to dynamically get the MVMailBundle class
and class_setSuperclass from <objc/runtime.h> to have your own class inherit from it
and then call registerBundle on it casted as MVMailBundle (requires include of MVMailBundle.h)
#import <objc/runtime.h>
#import "MVMailBundle.h"
#import "MyMailBundle.h"
#implementation MyMailBundle
+ (void)initialize
{
NSLog(#"Loading MyMail plugin...");
// since 64-bit objective-c runtimes, you apparently can't load
// symbols directly (i.e. through class inheritance) and have to
// resort to NSClassFromString
Class mvMailBundleClass = NSClassFromString(#"MVMailBundle");
// If this class is not available that means Mail.app
// doesn't allow plugins anymore or has changed the API
if (!mvMailBundleClass)
return;
// dynamically change super class hierarchy
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated"
class_setSuperclass([self class], mvMailBundleClass);
#pragma GCC diagnostic pop
// register our plugin bundle in mail
[[((MyMailBundle *)self) class] registerBundle];
NSLog(#"Done registering MyMail plugin.");
}
#end
add some NSLog logging calls to verify the right thing is happening, they'll be visible in XCode's console when running/debugging Mail.app from within XCode or alternatively in the system logs of Console.app
This should successfully run the plugin in Mail with no error!
The next steps involve crazy things like MethodSwizzling and ClassPosing to modify Mail's behavior, where GPGMail can be a helpful example. (Haven't been there myself yet)
For reference, here are some of the resources that helped me:
GPGMail
Adam Nash: Getting Ready to Write an Apple Mail.app Plug-in for Mac OS X - some good links, but apparently he never finished the project, so no code
James R. Eagan: Demystifying Mail.app Plugins on Leopard - using PyObjC to write a plugin in Python, explains the basic mechansims, very useful
Aaron Harnly: Mail Plugin Template - for XCode 2 I think, unfortunately the template (download a zip) doesn't work as template in Xcode anymore, but the code is still useful to look at
Aaron Harnly: Letterbox sources - from the same guy, but also from 2007, very outdated; contains a readme from the template, though it doesn't really help if you can't use the template.
There is no official supported way to build such a tool - you need to start trying to hook in to Mail.app without any official support.
If you want to persist on this sort of thing, then you'll need to understand how Mail.app internals work, which is a bunch of using the debugger and class dump to inspect libraries in other apps:
https://github.com/nygard/class-dump
You'll probably also want a way to inject code into other applications, for example:
https://github.com/rentzsch/mach_inject
And every time Apple update Mail.app you'll potentially need to redo everything :)
I have a header file that is included by both a native cpp file and a managed cpp file(compiled with /clr). It includes only native types, but I want to specify that the native types are visible outside the assembly
(see http://msdn.microsoft.com/en-us/library/4dffacbw(VS.80).aspx).
Essentially, I want:
public class NativeClass // The public makes this visible outside the assembly.
{
};
If I include this code from a native cpp, I get the following error:
error C3381: 'NativeClass' : assembly access specifiers are only available in code compiled with a /clr option
Attempted solution:
I'm currently using a preprocessor solution that causes the public to appear when compiling with the managed client, but it does not appear for the native client:
#ifdef __cplusplus_cli
#define CLR_ASSEMBLY_ACCESS_SPECIFIER__Public public
#else
#define CLR_ASSEMBLY_ACCESS_SPECIFIER__Public
#endif
CLR_ASSEMBLY_ACCESS_SPECIFIER__Public
class NativeClass
{
};
Question:
Is this the appropriate way to achieve this, or is there a better way?
Have you tried the make_public pragma listed on the MSDN page you linked to?
Otherwise, the solution you have is perfectly valid. I'm curious to know why you want to export native types from a CLR assembly though.