I wish to create a diagram similar to VS.NET class diagram.
I have seen Sukram's article on codeproject.com, called DiagramDesigner. But I have found this solution a little difficult to implement, I want the control with + and - buttons for expanding and collapsing.
Are there any vendors of a custom control similar to VS.NET Class diagram designer. Any ready solutions available?
Click of + the child nodes should expand. Click of - these nodes should minimize.
I have also seen Sacha Barber's spider tree control. But this too does not suit my requirement.
Have you looked into VS built in diagramming engine. You would be able to create your own DSL to define how you want your diagram to look and interact. You would then use VS's built in code gereration tools to generate the code and XAML you want.
Check out this webcast if you want to see a demonstration.
Related
I use the IntelliJ database plugin's ability to draw a diagram of a database schema.
Unfortunately, by default, the diagram functionality seems to lay out diagrams as code editor panes.
I don't want to split the editor pane - I want to dock the diagram, like a tool window - so I can control it and lay it out the way I want like any other tool window.
Is there a way to dock database diagrams into a tool window?
Not possible, as per #CrazyCoder.
https://youtrack.jetbrains.com/issue/IDEA-178091
Trying to reverse-engineer existing project and it would be of great help to see how classes collaborate/depend on each other. Is there a way to build project-wide UML diagram (or class diagram of any kind) in IntelliJ IDEA using build-in functionallity or using some free plugin?
Right click on your package no matter which. Click Diagrams > Show Diagram (Ctrl+Alt+Shift+U). You will see your package in diagram editor.
Now:
You can expand (E) or collapse (C) all nodes.
You can show dependencies
You can show many attributes of nodes (constructors, methods, properties...)
You can drag&drop other packages from project explorer.
So, play with it a bit and i think you will achieve what you need.
This is how it could looks like:
I'm looking for a way to inspect running XAML in a Windows 8 store app. Essentially, I want firebug / chrome inspector style functionality where I can look at the XAML source generated at runtime, to debug simple layout and style issues.
I've tried Snoop, Pistachio and WPF Inspector but none work for Windows Store apps. The only one I can find which seems to work for Store apps is XAML Spy, which is €90. I can't justify that cost.
Is there any other way to inspect running XAML?
WinRT XAML Toolkit now has an actual visual - visual tree debugger.
Get it from NuGet: nuget.org/packages/winrtxamltoolkit.Debugging then call WinRTXamlToolkit.Debugging.DC.ShowVisualTree() to display the debugger tool inside of your app. It's the third option so now you can use
the WinRTXAMLToolkit.Debugging.VisualTreeDebugger class - that enables you to debug the tree in your Visual Studio
XAML Spy - which is a great commercial visual tree debugger that runs in a separate window
and now this visual tree debugger in the WinRT XAML Toolkit that works inside of your app.
The VisualTreeDebugger class from WinRT XAML Toolkit is what you could use if you want a free tool. It doesn't do as much as XAML Spy, but you get what you pay for. I thought of adding more features to it like actual visualization of what you debug, but the work required would not justify the time investment + I didn't want to step on Koen Zwikstra's turf. I am sure he is doing a great job on that tool. Anyways - VisualTreeDebugger is enough for me, so maybe it would also be enough for you.
The way you can use it is add the class to your code, add a reference in your XAML like
xmlns:debug="WinRTXamlToolkit.Debugging"
then put a hook on a control where you would like to start debugging, like
debug:VisualTreeDebugger.BreakOnLoaded="True"
which will dump the core visual tree details as text in your debugger output window (Ctrl+W,O) and break in the code that dumped your tree where you can investigate the "path" variable, which contains the list of all visual tree elements from the debugged control to the root, so you can watch their values if what you need wasn't already dumped in the output window.
Other options include
debug:VisualTreeDebugger.BreakOnTap="True"
debug:VisualTreeDebugger.BreakOnLayoutUpdated="True"
debug:VisualTreeDebugger.BreakOnLoaded="True"
debug:VisualTreeDebugger.TraceOnTap="True"
debug:VisualTreeDebugger.TraceOnLayoutUpdated="True"
debug:VisualTreeDebugger.TraceOnLoaded="True"
Since it is source code and really a single simple class - you can easily add additional things to the code to do any custom debugging you need.
XAML Spy is what you need. You find it at http://xamlspy.com.
there is a new free tool called XAML Inspector. It's available through NuGet. Just search for "xamlinspector" or get if from the project page: www.xamlinspector.com
Greetings
Christian
I've a question. I cannot find the way, how to add buttons to main toolbar programmatically. My problem is, that I've the task to dynamically (based on XML configuration file) build menus and toolbar. I found how to add a menu item programmatically, but not toolbar button.
Tutorials mostly show how to create buttons and menus using plugin descriptor (plugin.xml), but not how to do it programatically. It seems, that it is out of bounds of Eclipse plugin philosophy.
I've just found this:
There might be layout problems with this approach. I also don't
believe the framework will try and re-create your dynamic item except
at random toolbarmanager updates. With Menus they can be updated on an
SWT.Show event, which is why CompoundContributionItem only applies to
Menus.
What shall I do? Can I say Sorry, there is no way to build toolbar dynamically. I can do it just for menus? Collegue says, that it must be possible, but he does neither know how.
The only way to be able to create main toolbar entries programmatically is in an RCP app, where you supply the ActionBarAdvisor for the workbench window. This isn't dynamic, however, just called on window creation.
Another way to do it would be to use org.eclipse.ui.menus and contribute org.eclipse.ui.menus.ExtensionContributionFactory. It also works only on workbench window creation (not really dynamic), but you could read your own XML and provide IContributionItems for the main menu or toolbar.
How dynamic are you trying to be? Most solutions work well on startup/window creation.
PW
Whenever you try to do something programmatically in Eclipse that is normally done through plugin definitions you are walking on thin ice. I've tried it on a few occasions and it rarely ended up being easy or good.
Instead, think of what it is that you only know at runtime and need to be able to change on the fly. Is it the name or icon of the button? That can be changed at runtime.
Take a look at runtime commands, they can be confusing to define properly, but with them you can for example create buttons that are only visible if a condition is active. That condition could be set at runtime.
(I'm something of an Eclipse newbie, so apologise for any dumbness on my part...)
I have a number of editors (derived from IEditorPart) in my RCP app, and a requirement has arisen that one particular editor needs to be also available in a modal dialog box (along with some extra controls) opened by one of the other editor classes. The editor to be embedded consists of the main viewer control, toolbar, and a couple of dozen helper classes (label providers, comparators, etc).
The options before me appear to be:
Find a way to put an editor area, IWorkbenchWindow-style, into a (JFace or SWT) Dialog.
Not had much luck searching for how to do this
Create a new WorkBenchWindow with a Perspective that just the editor area visible, and no views. Make this modal.
On trying this, the new window seemed to inherit things (menus etc) from its parent window.
Refactor the editor in question so all of it now resides on a single control, then embed this control in both the editor and the dialog.
Potentially time-consuming, given the number of places the helper classes refer back to the main editor object.
If it turns out that this is a truly perverse and anti-idiomatic thing to want to do, in Eclipse terms, can you suggest a wiser course of action?
Thanks
EditorParts are meant to be inside workbenchwindows. There is a lot of code that depends on this behaviour. So I would suggest not to do (1). If the result is acceptable (a workbench window, which is modal), the easier way is to hang on to (2).