In our application, we allow administrators of an install to design templates for name tags that are printed when they check-in from a kiosk (sort of like checking in for a flight at a kiosk and printing out a boarding pass).
For example, the template might look something like this:
[FirstName] [LastName]
[Company]
[PersonImage]
[BarCode]
Right now, we use Reporting Services to allow our administrators to design templates for name tags (some might want a picture of the person, a bar code printed out, name of their organization, etc). This works ok, but 1) Reporting Services is slow to render and 2) it's not integrated with our application very well -- they have to load up Visual Studio and design the name tag outside of our application.
XAML seems like a good fit for designing the template for name tags. Virtually any design could be handled with the format and we could use XAML to XPS to print.
The problem I'm seeing is how to integrate a visual designer that uses a subset of available XAML controls. We'd really only need simple controls such as Canvas, Grid, TextBlock, Image, etc with drag/drop support. I'm not finding much info on whether or not it's possible to host Visual Studio or Sparkle's XAML designer into a separate application. Anyone have any ideas? The RichTextBox looks like it would almost work, but a FlowDocument isn't really want we're wanting. We need to be able to drag items around and absolutely position them (like in a report designer).
I'm not sure whether you can host the MS designer/s (although I doubt it), but I think you might be able to produce your own mini-editor fairly simply. Start with a Canvas and programmatically add Labels, TextBlocks or whatever else you want (wire them up with Click handlers to move them around via Canvas.Top/Canvas.Left). You can render the Canvas to an image fairly easily for printing, or Xaml-Xps as you mentioned.
Check out Kaxaml as an example of someone who has already whipped up a mini Xaml editor (it was recently updated to SL2). There may be others out there as well.
EDIT 26-Jan-09: also check out Charles Petzold's XamlCruncher (example) - certainly beats loading up Visual Studio - seems like XamlReader.Load might be worth trying out?
Related
I'm designing a UI in WPF and want to be able to share the progress with a client. I could run the program and take a screenshot (Snipping Tool, etc.) or do the same with the results in the designer window. However, ideally I would like to avoid those manual steps (e.g. running the program, scaling the designer window to fit the entire UI, selecting the proper screen area to capture), because the designer has already rendered the UI for me. I'm wondering if there exists a more convenient way to export what is already rendered for me in the Visual Studio 2015 XAML designer window directly to a high quality image. I couldn't find (by looking through VS and search engines) an obvious way to do it, but perhaps someone knows of a way (or plugin/extension)?
I want to create an automated UI test that will test my syncfusion grid. My problem is that the recorder can't recognize this control (or any syncfusion control). I've searched a lot in the internet but I couldn't find any extension so the recorder will recognize my controls (I'm using WinForms, not WPF!), or at least a way to extend the recorder abilities so syncfusion's controls will be recognized somehow.
Is there any easy way to extend the recorder? Or is there any extension available?
Or maybe can I get the grid object from the WinClient that the recorder generates?
Thanks!
Start your program. Run the Spy++ utility. Type Ctrl+F to start the finder tool and drag the bulls-eye onto your form. Ok, Synchronize and have a look-see at the windows that are visible in the tree. If you see regular Windows Forms controls, like a Button or a Label, but not any of the SyncFusion controls then you've probably found the source of the problem.
Component vendors that try to improve .NET controls typically do so by creating 'window-less' controls. They are not really controls, they don't derive from the Control class and don't have a Handle property. They use the surface of the parent to draw themselves, making them look just like controls. The .NET ToolStripItem classes do this. And this is also the approach WPF uses.
The big advantage is that they render quickly and support all kinds of effects that regular controls can't support, like transparency, rotation and anti-aliased window edges. The big disadvantage is that the kind of tool that you are using suddenly gets noddy and can't find the control back. Because they work by finding the Windows window back on your form, there is no window for them.
This is a hard problem to solve, the 'control' exists only in memory and there's no good way for a tool to find it back. Using Accessibility is about the only other way for such a tool to find a control that I can think of. Which would have to be implemented by the control vendor first, a somewhat obscure feature that gets easily overlooked. You really do need the help of the vendor to find a workaround for this. Shouldn't be a problem, that's why you paid them the big money.
This is Rajadurai from Syncfusion. Thank you for your interest in Syncfusion Products. To make UI Test Automation recognize Syncfusion grids(WinForms), some internal support need to be provided in grid whose implementation is in progress and about to be completed. Please submit an incident through Direct-Trac for any further related inquiries in the following link.
http://www.syncfusion.com/Account/Logon?ReturnUrl=%2fsupport%2fdirecttrac
You can also contact us through support#syncfusion.com. We are happy to assist you.
Regards,
Rajadurai
When I try to use Morae Manager 3.0 to run a Screen Text search on a recording of our prototype (coded in WPF, .NET version 3.5 SP1), the only things that come up are the window titles. We are using Windows XP.
Even when I search for something that is editable, like text typed into a text box, it does not come up.
Screen text for things outside the prototype (e.g. desktop icons) still comes up perfectly.
I contacted TechSmith support on two separate occassions and both times the reply I got was it must be an issue with our technology, since the screen text search does work for other things, and that the support people are not developers and thus do not know what might be causing this.
Does anyone know:
what precisely might be causing this -- e.g. does WPF's rendering engine bypass some sort of Windows layer where Morae looks for text (please forgive me for any errors in terminology)
if there is anything I can tweak in the prototype to fix it
how I can get through to someone at TechSmith who knows the answers to 1. and 2.
P.S. Morae is a wonderful product and we've usually had great support from TechSmith. We are only having problems with this one little thing, and one can hardly blame Morae for not being compatible with something as new as WPF.
I have no idea what Morae is or how it works, but one big difference between WPF and for example WinForms is the following, copied from here:
When you create a WPF Window, WPF
creates a top-level HWND, and uses an
HwndSource to put the Window and its
WPF content inside the HWND. The rest
of your WPF content in the application
shares that singular HWND.
If Morae depends on HWNDs to find texts on the screen, this could explain why it can not find the text box. In contrast, i believe in WinForms every control (button, textbox) has its own HWND.
Visual Studio 2008 does a much better job of detecting and adding controls from projects to the toolbox for use in the forms designer. If you have an assembly with a UserControl- or DataSet-derived type, then it will automatically detect and add that control to the toolbox for designing forms. This is slightly better than the old system in 2005 that made you manually add controls and would occasionally forget them, etc.
However, on the legacy, monolithic project I am working on (now upgraded to vs2008) this means many controls that I don't want and don't need (and a redesign would not be warranted against so much legacy code :( ). I imagine that if I made certain types internal or private, then they wouldn't show up. However, I need many of those to remain public, but not show up in the toolbox. Furthermore, with so many controls getting added to the toolbox, opening the winforms designer slows significantly.
Is there an attribute or other mechanism that prevents toolbox appearance (that wouldn't otherwise affect functionality) ?
Would filtering using such a mechanism improve performance while still autodetecting new types that SHOULD be in the toolbox? (I know you can disable the autodetect, but its nice to have in many cases)
Have others encountered this irritation on large solutions (with many csproj/vbproj files)?
Edit: Thanks everyone! I knew it had to be simple (and was likely an attribute) but that fills the gap. Nice to know that I was in good company in not knowing about ToolBoxItem(false).
The following attribute should hide it from the toolbox:
[ToolboxItem(false)]
If you apply it to all the types you don't want to show, it will still show any new ones you create without this attribute. Note, you may have to manually remove the items to start with.
This blog post shows some other attributes you may want to use.
Go through the toolbox and for each custom control that you see that you want to hide, add the following attribute above the class:
[ToolboxItem(false)]
Of course, this is a compiled attribute and will affect everyone using the code, so I only recommend doing this for controls that don't make drag-drop sense. Otherwise, you will probably make someone that loves that control very very angry. :)
We are trying out Visual Studio 2008 and Expression Blend on a new project. The goal is to clearly define the role of the developer and designer as separate, but reap the benefit of the developer being able to directly consume the XAML produced by the designer.
For the most part this has worked great, and I really like the possibilities. One difficulty we have come across though is designing against DataBindings. In many cases, the GUI does not populate rows, or other data structures unless the application is run, and a database call is made. Consequently the designer does not have access to the visual layout of the GUI.
What I would like to do, is somehow create some simple stubbed or mocked data that the designer can use to work on the design. The big goal is to have that stubbed data show up in Expression Blend, but then be applied to the real collection at runtime.
Has anyone found a solid method of doing this?
I would suggest reading this blog. The final method seems to work well, your test data shows up in Blend very nicely. Just keep in mind that you have to compile the DLL before it will display the data.
I would look into creating XML data islands which emulate the structure of the objects you will eventually bind the UI to. This way your designer can bind the root element of the page (or user control, etc.) to the top level of your fake XML data island and all the relative paths will stay the same when you swap that data island out for the real DataContext binding.
there will be some degree of refactoring to attach to the real object when you are ready, but that is why your developers should at least know enough XAML to know how to modify the bindings properly.
it looks like the commenter above me has a link to an example of this.