Subscribe to this thread
Home - Cutting Edge / All posts - Manifold System

8,634 post(s)
#28-Dec-17 18:19

SHA256: 9109c70c3cb031b03df1722316737a47d473e61ad321af610816e41ce4b4b0d5

SHA256: cde8e11464e8222d9056507a57b134937eee213c36232970da1b26cf4627592a


8,634 post(s)
#28-Dec-17 18:20


Format pickers for layout frames in the Record pane show format values even if those values cannot be edited (for example, because the layout component is readonly).

Format pickers for layout frames in the Record pane show rotations and sizes as they are shown in the Style pane. (Numeric values instead of format samples).

(Breaking) The names of properties used to store font sizes in labels and layout frames have been changed to follow the unified naming scheme.

Zooming to a point from the Record pane keeps the current scale. If the point is already visible in the window and is not on the edge of the view, zooming to it keeps the current view entirely.

The Record pane shows formatting values for drawing objects in the Style tab.

Drawings support per-record formatting. Per-record formatting is controlled from the Style pane. To turn per-record formatting on for a particular drawing, create a new text field, open the drawing, open the Style pane, click the Per-Record Style button at the top, then check 'Use per-record style', select the created field to store per-record style data in and click OK. The Record pane will then allow changing formatting values in the Style tab. A particular record can override only a subset of formatting values or it can override all of them.

Format pickers in the Record pane indicate overridden formatting values using an icon and allow resetting overridden formatting values back to the defaults using the 'Default' choice in the dropdown menu.

The Record pane protects the field used to store per-record formatting from being edited in the Values tab by making it readonly.

The Record pane disables editing per-record formatting if the field used to store formatting data is computed (and thus readonly).

The PBF dataport displays progress and allows canceling the initial caching phase.

All dataports that expose maps are now using the new map storage format.

Dataports for Oracle and other databases use a long text type for the value field in the MFD_META table.

The OLE DB dataport supports UUID fields.

Dataports for SDE and similar technologies built on top of databases allow names that contain quote characters. (This was the last bastion in the big fight for removing all restrictions on names in databases except those imposed by the database itself.)

End of list.

Mike Pelletier

1,602 post(s)
#29-Dec-17 21:16

Glad to see per-record formatting added to the style options and that it stores formatting information that is transferable to other projects. Perhaps this is just an initial implementation but I'll add some thoughts.

1. Why not just have the software add a field (perhaps the name "mfd-format") to store the formatting info? Maybe it has something to do with the ability to use a computed field? How are you seeing that ability to be used?

2. It would be nicer if we could select multiple objects and apply per-record formatting to the group rather than having to do it one at a time.

3. Along those same lines, it would be nice if a single click could apply all the objects style settings (color, size, etc.) at once rather than having to do it individually. For example, set up a style called "fire hydrant" and reuse it for other objects easily.

I'm sure all these things have been considered and I've submitted this before so perhaps the above isn't helpful.

Lastly, it seems the area hatching styles do not work.

Happy New Year to all :-)


5,491 post(s)
#30-Dec-17 05:01

Yes, it is a very initial implementation, mainly there to allow proofing and feedback, and the many options one would like for per-record style are in the works. Those require more room in the interface so today's build introduces interface changes for going forward.

Instead of a big per-record button the Style panel acquires a tab strip like the Record panel, so an Options tab can host the expanded set of controls that will be added to support and to exploit the many interactive GIS / cartographic possibilities that per-record style now allows.

Per-record style appears now, by the way, because it is a good idea to use the same infrastructure not just for styling objects in drawings but also for labels from drawings, for text boxes in layouts, and, for that matter per-object styling for frames in layouts. The general idea that "everything is a table," so whatever it is (a label, a text box in a layout, a layout frame, an object...) is a record, and that record provides the info for that thing, including a specific style if desired, opens the door to endless richness.

The facility certainly will do things like add a default field (item 1) automatically if one is not there, similar to how creating drawings at first in Radian was a manual process of adding necessary fields and then became automated with defaults added in Future. But the idea that it is a field is the big open door, and that you can specify your own field if you want is a yet wider door. For example, you could have many fields that carry per-record style info and switch between them programmatically, or you can use queries to select all non-NULLs and to change them all at once.

That is what is in item 2, which can be done today using the Transform and Select panels, or with queries, but which further can be automated with point and click controls in the Style Options tab. That they can be done so easily with a query makes it really easy to wire up a point and click control. Likewise object 3.

Hatching: as before, that depends upon the rendering engine. We'll get that sorted as part of introducing many more styles.

Thanks for the tips, and keep them coming!

Hey... it's not New Year yet! ... a few more steps to go. :-)

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.