Hi

I have just noticed that the version number on the Diagramming.WPF dll you just provided is 4.3.1.29488, where as the one you gave out in October was versioned as 4.3.1.30344

Could you confirm that this is correct as there are some issues occuring during use:

When ever scrollbars are enabled on the control it appears to have a catastrophic effect on the solution (no further builds possible) and the size of the diagram canvas area seems to have a hard coded default, where by the width is 20x20, although it's shape on the form is rectangular. 

It seems that the control defaults to a particular size (regardless of size drawn on form) and then dynamicly resizes during run time use if it detects that it is neccessary.


Many thanks

Regarding build numbers, fair enough just needed to be sure.

For info, my environment is Windows Vista using VS 2008 (Beta) and Expression Blend.

The following are steps I take that will reproduce issues.

1.
Using VS2008, create a new project, add references to Mindfusion DLLs, add Diagram object to toolbox.  Double click diagram icon to create Diagram control on window; generates "The property 'FrameworkElement.Width' is read-only and cannot be changed."  Same message generated if control drawn manually.

2a.
Using Expression Blend, create a new project, add references to Mindfusion DLLs, add Diagram control to toolbar and double click to create on window.  By default the following values are set:
Width=20
Height=20
Diagram.Width=20
Diagram.Height=20
Bounds=0,0,210,100
HorizontalAlignment=Left
VerticalAlignment=Top

My form is:
Width=640
Height=480

With the diagram control selected, it fills the width of the form, over hanging by about a quarter of the form width.  It fills about 85% of the height of the form.
Any attempt to modify the height or width of the control (not the bounds) by manually changing the values results in the message "The element <element name> could not be displayed because of a problem with System.Double.  Object reference not set to an instance of an object."  Reverting to 20 fixes this.


2b.
Continuing from above, resize diagram control to match form width (640) using the controls handles.  Width properties on diagram control remain at 20.

2c.
Changing control horizontal alignments to either Right or Stretch causes the handles of the control to be moved out of alignment with the visible control area - it seems to align the handles to its bounds.  The same occurrs with vertical alignments Bottom or Stretch.

Enableing scrollbars on the ocntrol seems to cause VS an issue, but this may be just a VS thing.

Hope any of this is useful to you guys.


Regards

This version should work better:
https://mindfusion.org/_beta/wpf_zoom2.zip

The problem was that the control had an attached property called Width, used to set the widths of diagram items. Instead of setting the Width property derived from Control, VS was trying to assign to the attached property trough the Reflection API, but without actually specifying an item for which the value should be set.

Now we have renamed the attached properties to ItemWidth and ItemHeight, and it seems this fixes the problem.

Stoyan

Hi,

Here are several methods of doing that:

// how to set bounds of custom nodes
Rect bounds = new Rect(60, 40, 20, 20);
Button b = new Button();
d.Items.Add(b);

// variant 1 - using attached properties
Diagram.SetItemTop(b, bounds.Top);
Diagram.SetItemLeft(b, bounds.Left);
Diagram.SetItemWidth(b, bounds.Width);
Diagram.SetItemHeight(b, bounds.Height);

// variant 2 - shortcut version of variant 1
Diagram.SetItemBounds(b, bounds);

// variant 3 - using FrameworkElement.Width, FrameworkElement.Height
// Top and Left cannot be set this way
b.Width = bounds.Width;
b.Height = bounds.Height;

// variant 4 - using DiagramNode adapter class
DiagramNode buttonNode = (DiagramNode)Diagram.GetDiagramItem(b);
buttonNode.Bounds = bounds;

This version just renames the Top and Left attached properties to ItemTop and ItemLeft, for consistency with the ItemWidth and ItemHeight property names:
https://mindfusion.org/_temp/wpf_att.zip

I hope that helps,
Stoyan

Hi Paul,

This is by design, the Brush property setter throws an exception when the assigned value is null. This is probably needed only for the Windows Forms version. The compositing system in WPF is much better and perhaps we can safely use what's behind the diagram as a background when the brush is null. However we are now close to releasing the first version of the WPF control, so we won't change this behavior, but can implement support for null-brushes in the 1.0.1 release.

Stoyan

Yes, we'll have a separate forum for the WPF version, and will move this thread there for a start  8)

Stoyan

What exactly is wrong with Diagram.Bounds?

If you need to auto-scale the diagram so that it always fits the visible area, I believe the WPF Viewbox control can help you with that. Viewbox auto-scales its content to fit the available space. We haven't tested how the Diagram control works inside a Viewbox though. If there is some functionality that Viewbox expects from its contained controls and is missing from the Diagram, then this will have to wait for the 1.0.1 release 8)

Stoyan

I think I get it now  8)

Regarding increasing the bounds size, you must call ResizeToFitItems after creating nodes programmatically. That's not done automatically after adding a node from code, because resizing the bounds invalidates the WPF container layout. That could slow down your application a lot, e.g. if you add a few hundred items in a loop.

Stoyan