Of all the methods to get our Illustrator files into pretty XAML, I've found that using Expression Design 4 makes the nicest vectors for me.
However, this is not the case when using WinRT libraries, such as those in my Windows Phone 8.1 project.
Exporting as WPF Resource Dictionary uses libraries that can't be found. Of course, the Silverlight exports also don't work.
i.e. With the WPF Resource Dictionary I get:
The type 'GeometryDrawing' was not found.
The type 'DrawingGroup' was not found.
The type 'DrawingBrush' was not found.
Verify that you are not missing an assembly reference and that all referenced assemblies have been built.
i.e. With the Silverlight I get:
The text associated with this error code could not be found.
Failed to assign to property 'Windows.UI.Xaml.UIElement.Clip' because the type 'Windows.UI.Xaml.Media.PathGeometry' cannot be assigned to the type 'Windows.UI.Xaml.Media.RectangleGeometry'.
Taking an Illustrator to SVG and then to XAML seems like a worse option.
Has anyone found a way around using their of these two as options?
Or another way using Expression Design?
Or another tool etc?
tia
Related
I'm writing a converter from HTML to FlowDocument - an XSD that defined the elements and attributes of a FlowDocument would be invaluable, if anyone knows of one.
The Flow Document schema uses the namespace of Windows Presentation Foundation. You can find the XSD in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Xml\Schemas (location can be slightly different depending on version of Visual Studio). It is called wpfe.xsd.
However, I cannot find FlowDocument or other elements defined there. In fact, I cannot find it in any of the XSD's defined there, so that is not really helping.
Microsoft redefined the target namespace in this document from http://schemas.microsoft.com/client/2007 to http://schemas.microsoft.com/winfx/2006/xaml/presentation, which is very unfortunate, because that means that the schema does not match even the target namespace. Some discussion on this can be found in this thread and in this Microsoft page on Silverlight (similar story).
Long story short, unless you can find it embedded in one of the .NET libraries, you may be out of luck and the closest you can get is XAML, which is defined in xaml2006.xsd in the same location.
I'm hoping I just missed something in the README somewhere, but...
I have a library of VB.net code that I'm trying to package into a PCL, ultimately for use under Xamarin. The code is relatively straightforward, there's a lot of File I/O using streams and some SQL client code, and a smaller amount of UI and control related code.
So I made a new PCL project, but I was confused what to select, so I chose Windows Store and .Net 4.5. I then Add...ed the source files from an existing project. Now I'm getting errors on the most basic things - ArrayList does not appear to exist in spite of importing System.Collections, and StackTrace doesn't exist in Diagnostics. Even simple things like StringFormat and SortedDictionary aren't there.
Did I skip a step somewhere? Perhaps I didn't download the right libs from MS? Or maybe I have to manually include a Reference to something? Any ideas?
Before anyone bashes me with, read this first and that second, I have tried following links below to achieve internationalization with MFC.
Creating resourse DLL:
Localization of MFC Components
http://msdn.microsoft.com/en-us/library/x6h91d9w.aspx
Localization for older MFC
htp://support.microsoft.com/kb/198846/en-us
I am new to MFC so please be kind with your answers. So in order to get localization with MFC 7 and above I followed these steps. (Currently using MFC with Visual Studio11)
Created a MFC Project (MyApp) with MFC in a shared DLL
To add a another language (German) to the app, I created a win32 Dll project (MyAppDEU)
Copied the resource file (MyApp.rc) inside same folder and renamed it MyAppDEU.rc
Added the MyAppDEU.rc file to the dll project
In resource view of MyAppDEU.rc, changed the VS_VERSION_INFO -> Block header to "Deutsch (000704b0)"
Changed some strings in the string table to see the difference when the main app loads
Changed the ouput of the MyAppDEU project to build inside the MyApp Output folder
Compiled MyAppDEU to get the Dll
Compiled MyApp with and without following the instructions from point 9
http://support.microsoft.com/kb/198846/en-us
So with all these done, I failed to see any difference in my Application. It loads with the English resouce file which I created the App with. My computer has a German Windows 8 OS. From what I know MFC has inbuilt multilanguage support with Satellite Dlls. I have the correct naming format ApplicationNameXXX.dll. The dlls are in the same directory as the exe.
I hope someone can see what Im doing wrong or missing here. I am fairly new to MFC and appreciate any help regarding this.
[answer adaapted from this SO answer]
I have used a slightly different approach successfully, skipping the MFC inbuilt multilanguage support with Satellite DLLs.
We have multiple DLL projects in our solution, each one containing just one set of resources for a single language (e.g.: AppRes_ENU.DLL). At run-time InitInstance(), we select the appropriate language DLL with code like
CString sResourceDllName;
// format sResourceDllName according to the language ("%s\AppRes_%s.DLL")
hInst_aRes = LoadLibrary(sResourceDllName);
if (hInst_aRes == NULL)
{ // handle <resoure-DLL not available>
return FALSE;
}
AfxSetResourceHandle(hInst_aRes);
and use hInst_aRes to load strings, dialog boxes, ...
Have a look at this software: http://www.apptranslator.com/ . It helps with localisation using satellite dll's; the documentation probably describes how to do it. It's quite simple once you figure our the relationships between ::AfxGetResourceHandle() and hInstanceHandle and all that jazz - the easiest way to learn about that is to read the MFC source. Then you write a few helper classes and off you go :)
I'm trying to interact with a .dll which will allow me to receive information from a variety of devices (Eye Gaze to be specific). The .dll is called ETUDriver and can be found at http://www.sis.uta.fi/~csolsp/projects.php however it does not come with an accompanying .h file.
I am struggling to actually load, interact and invoke functions from the .dll. A manual is supplied but it is of no help whatsoever with regards to actually setting up the code to start it off. There are three accompanying example apps (with source code) but only two of these work and one of which is in C# so is not helpful. The one that works however loads up the .dll via MFC and this is not a viable option with my code (which is intended to be used with many other projects and as such can't enforce MFC or any other libraries that are not as standard to projects).
Essentially, within the .dll is a series of classes which I need to create within my code and invoke the relevant functions of that class.
I've tried to use HRESULT hr = CoInitialize(NULL);
hr = CoCreateInstance(__uuidof(ETUDSink), NULL, CLSCTX_INPROC, __uuidof(IETUDSink), (LPVOID*)&pETUDSink);
if(pETUDSink)
{
pETUDSink->Start();
} however it always returns an error saying that the class is not registered. I can't use MFC to call the relevant .rgs file and am completely stuck on how to get this to work otherwise.
Is there a given format to doing this that I am unaware of and has anyone had experience in using the ETUDriver (or is able to get it working in C++ without use of MFC)?
Thank you for any help you can provide on this subject :)
I am not familiar with the specific DLL in question, but it sounds like you did not register the DLL on the target machine. You can do this by running regsvr32.exe or by calling the DLL's exported DllRegisterServer function or by using side-by-side assemblies. You need to do register the DLL on each machine that needs to leverage the COM functionality within it, so when you distribute your application, make sure that your installer registers the DLL if you go the regsvr32.exe route.
You can use the #import directive in Microsoft Visual C++ to load the information contained within the DLL without using a header file or rewriting it yourself based on documentation.
I've just installed Blend 4 and are trying to use it with a rather big VS2010 project that includes a couple of C++/CLI assemblies with some native code. For a lot of controls I get a Blend error like 'The name XXX does not exist in the namespace 'clr-namespace:YYY' when trying to open the design view.
I've searched the web (including this forum) for similar errors and have made sure that I've followed all available suggestions, like e.g. making sure I have an AnyCPU configuration, that I don't use e.g. 'x64\Debug' as the output folder, and that I have the proper namespace declaration in my XAML (using 'assembly' in my clr-namespace declaration).
I've also made a simple, new project that only accesses one of the assemblies with the issue, but I still get the error.
It looks to me that the issue is related to assemblies that references any of the C++/CLI assemblies that includes some unmanaged code. I do not seem to get the error for assemblies that references managed-code-only assemblies.
What could cause the errors ?
Regards,
Leif
Little response here, so maybe I should rewrite my question a bit:
Has anyone successfully used Expression Blend for a project that uses assemblies with unmanaged code ?
Regards,
Leif
had a similar problem: project compiled correctly without error in VB 2010, but got error when opening it in Expression Blend 4 (beautyful tool, by the way):
The name XXX does not exist in the namespace "clr-namespace:YYY".
at line:
<CollectionViewSource x:Key="YYYViewSource" d:DesignSource="{d:DesignInstance {x:Type my:YYY}, CreateList=True}" />
In my case it was an Entity in my edmx, a FunctionImport named "YYY" with a ComplexType "YYY_Result", and my XAML code at the CollectionViewSource referenced to that entity "YYY".
This XAML code generated No error in VB 2010, compiled and ran perfectly well (compiled also correctly in Blend), however no design view in Blend.
Solution: I realized my mistake at the x:Type in CollectionViewSource and corrected name from "YYY" to "YYY_Result" and it worked:
<CollectionViewSource x:Key="YYYViewSource" d:DesignSource="{d:DesignInstance {x:Type my:YYY_Result}, CreateList=True}" />
Conclusion:
Maybe this answer is not exactly related to your problem concerning the C++/CLI assemblies with some unmanaged native code, and maybe yes.
This case was just a nice example of a project compiling correctly in VB 2010, but same XAML generated above error message in Blend 4 when creating the design view (many users reported similar issues at this forum).