I tried to serialize a FrameworkElement with DavidPoll's XamlSerializer, but I get a totally different result than the (right) one that I get with Silverlight Spy. For example with XamlSerializer I get alot of empty tags(like MatrixTransform, ScrollViewer etc.) but not the ContentPresenter node that I get with Silverlight Spy. Any idea how to get a clean logical tree at runtime?
Update: I have a form designer program that stores those forms in a DB and at runtime it creates objects (user controls) from that info stored in a DB. Each form is composed of some fields. At runtime it programmatically creats an UserControl that contains all fields. I would like to get the generated XAML, just like I can get it with Silverlight Spy.
edit: I'm not limited to Silverlight environment, a soltion for a desktop application is valid too.
Short answer is: I don't think you can from within Silverlight itself. Sorry.
Once the XAML has been parsed and loaded into framework elements you have already lost information. For instance regenerating a path from the in memory object is non-trivial and you won't have access to the internals of the path element from Silverlight code.
Silverlight Spy adds back information that a simple XamlSerializer won't generate. Silverlight Spy has no limitations as it is a "real" desktop application, with full operating system access, whereas you want to actually do this in Silverlight itself which is very restricted sandbox environment (for security reasons).
Related
I am working in WPF and WinForms for both Windows XP and Windows 7/10 users (.NET 4.0 due to XP).
Some WPF Windows are used as dialogs for older WinForms applications without a WPF Application class/App.xaml file.
This in itself isn't a problem but I find I'm having to declare styles in resource dictionaries in user controls/windows in the WinForms/WPF situations which isn't normally necessary in plain WPF applications due to App.xaml.
My question is whether WPF detects that the same resource is being loaded twice (in a pure WPF application e.g. UserControl and App.xaml) and copes with/manages this without interference from me or do I have to try to ensure I only declare resource dictionaries once?
Many thanks.
The answer is no.
If you load a resource dictionary as a resource for a usercontrol then each instance of the usercontrol means another instance of any resources it uses in memory.
If that is going to be a problem then you need to do something.
You might just be able to instantiate an application object and use that to stash your resources in. Application.Current.Resources is after all just referencing the current application. Depends on exactly how your app works.
If you try to load the same resource dictionary twice, the application will throw a runtime error.
But, if you are only defining the styles already present in the resource dictionary, in the user control also, i.e, basically two styles with the same name one in the resource dictionary and the other in the user control, then no error is thrown. The style in the user control will have a higher priority.
VS 2010, Windows 7: Windows Forms - I have a number of forms that contain user controls that reference domain model objects. Some of the controls reference single objects and some reference collections of domain model objects. When I open the project or individual forms, the IDE will check out the forms and add dummy domain model objects. In some cases, this has no serious side effects and in others this result in the app crashing. Why is this happening and how do I prevent this from happening in the future? I would like to get to the point where the designer doesn't add anything extraneous - I can crash the system on my thank you very much. Thanks.
The designer will create a default instance for each public property contained in child user-controls in the current control it is displaying. This can be changed using the DesignerSerializationVisibilityAttribute setting the visibility to DesignerSerializationVisibility.Hidden.
This tells the designer to leave those properties alone.
You will likely have to go through the designer file itself and remove the old allocations and assignments for the properties you marked.
I am building an application in the MVVM style where the actual views (UserControls) are stored remotely and hopefully sent via a WCF service to my main application window. I am doing this in order to avoid having the user reinstall the application each time a new view is added. However, when I try to return a User Control from my WCF service I get an error stating:
System.Runtime.Serialization.InvalidDataContractException: Type 'System.Windows.Input.TouchDevice' cannot be serialized.
I am wondering if there is any way around this or if people have implemented something similar in other ways?
Thanks,
Ochowie
When you're loading from an assembly you're instantiating the compiled object from an assembly, which is a lot different than a deserialization operation, which is what is happening with a service call. The best you can do with serialization is transfer raw XAML that can be loaded with XamlReader, but this limits what you can do with a control since you can't use any code. If you're really set on hosting controls on your server the most flexible option would be to have your app download an assembly containing the new control and dynamically load the new assembly or use a separate launcher that can download new control assemblies before starting up the main application (make sure you take the time to understand the security implications and secure the assemblies and downloads).
What you're trying to do doesn't really make sense... controls are not DTOs, they're strongly dependent on their runtime environment. In WPF, there is also the issue of the dispatcher : even if you could transfer a control, how would you reattach it to your application dispatcher ? Anyway WPF controls are not serializable with the DataContractSerializer, and there is no way to change that.
However, what you could do is transfer a representation of the views in XAML. This is of course assuming your views are XAML only, without any code-behind. You could then load the views using XamlReader and render them in your UI. I'm not sure of the feasibility, but I think it's your best option.
You could also implement your views in a separate assembly, so that the users don't need to reinstall the whole application. They will only need to upgrade the modified assemblies.
I'm attempting to host an ActiveX control in a WPF app. After attempting to use existing info on the web and here, I've hit a dead-end.
I need to use an ActiveX control provided to communicate with a UV power meter. They provide an application that registers and uses the control and even includes some useful demo apps. I stripped out the OCX file and put it here if needed. You won't have the power meter to talk to, but the app and demos will still load the ActiveX control successfully.
I created a simple Windows Forms application. I was able to bring the ActiveX control into the toolbar, drop it into my form, and everything is fine. The demo apps they provide do this as well.
However, getting this to work in a WPF environment is another story. The control can't be added to the toolbox and "dragged" into the app.
So far I've tried two techniques:
Technique found here. I am able to add a reference to the control, but then I enter namespace hell. The xmlns:ax namespace it suggests making cannot find the information. Here's my attempt based on what the object viewer tells me: xmlns:ax="clr-namespace:OphirUsbXLib;assembly=Interop.OphirUsbXLib"
Technique found here. This is essentially to create a new project that creates a library based on Windows Forms, which contains the ActiveX control (yikes). I am able to add the Windows Forms Host, but I cannot get access to the ActiveX control within. I can make the control public, but I still cannot call methods etc. This doesn't look like the right solution.
In short, I have an ActiveX control that works beautifully in Forms, but is a real bitch to get working in WPF.
Any insight is appreciated!
In this situation I would consider making a WinForms usercontrol which wraps the ActiveX control you are trying to use.
You could make public properties and methods which expose each of the required properties and methods on the ActiveX control, and then host this WinForms UC on the in a WPF WinFormsHost control.
I have already done something similar to this, in reverse, hosting a WPF UserControl in a WinForms UserControl, then hosting that on a VB6 Form in a legacy application.
Overview
In another question, I asked about deploying localizations for some runtime compiled UserControl's. However, before I can get to deploying the localizations, I need a way of localizing the controls.
Background
The controls are created by our own WinForms-style designer (using .NET's support for design surfaces, etc.) and saved as a binary format that combines the CodeCompileUnit, resource resx, and user source into one file. These files are then compiled into an assembly as appropriate at runtime by another tool.
In order to localize these, we need to tell the designer and serialization that localizable property values are to be stored in the resources. The VisualStudio WinForms designer does this using an extension property called Localizable and an associated property for specifying the default culture. We need this property in our custom designer, if possible.
Constraints
We need our standalone designer tool that is easy to use for non-developer types as well as restricting certain actions so using a free edition of Visual Studio (i.e. C# Express) is not going to work (I've already pitched it and failed); therefore, any solution to how we localize these UserControl's needs to compensate for this.
Question
Can we get the Localizable support into our custom WinForms designer?
If yes, how?
If no, what alternatives are there to localizing our UserControl's? e.g. post-processing somehow, different file format, etc.
I'm not sure if I understood your question correctly.
Just check for the System.ComponentModel.LocalizableAttribute on all properties to (de-)serialize if your control is Localizable.
// Gets the attributes for the property.
AttributeCollection attributes =
TypeDescriptor.GetProperties(this)["MyProperty"].Attributes;
// Checks to see if the property needs to be localized.
LocalizableAttribute myAttribute =
(LocalizableAttribute)attributes[typeof(LocalizableAttribute)];
if(myAttribute.IsLocalizable) {
// Insert code for handling resource files here.
}
Since you decided to write your own designer you have to do this yourself.
You need to add a System.ComponentModel.Design.LocalizationExtenderProvider to your design surface.