9.0.175.3

manifold-9.0.175.3-x64.zip

SHA256: 5489bea6ab27a18bb261d39d5eebc2dd573c3b52408df54861a93aefb77354e2

manifold-viewer-9.0.175.3-x64.zip

SHA256: b68a0ded39fdab72891c32236c8732d279277f24a58fe4288ad0264c855c7878

sql4arc-9.0.175.3-x64.zip

SHA256: 2767d0c433aafd38ed67a9361121f46be700a0fe4f5cc3ed54195262f7a0d927

We reworked labels to use a text pattern instead of a text field, applying this change to storage / painting / printing, etc. A text pattern is much more flexible than a text field not only because it may reference more than one field, but also because you may use it to alter label text easily without altering the table (which can be very big or which you may not have permissions to alter). Future builds will include means to format field values in the pattern, and will include various improvements for rendering labels.

We are also gradually extending support for GDB. Future builds will include several updates specific to SQL for ArcGIS.

Changes

Labels are reworked to compose text from zero or more fields instead of always using a single field. The text used for labels is specified as a pattern that may reference fields using the '[...]' syntax, similarly to Manifold 8. The plain text parts of the text pattern may contain escaped characters (\[, \], \\, etc) as well as Unicode sequences (\uxxxx, eg, \u00a9 is a copyright sign). Unknown fields are rendered as '***'.

Label text may contain expressions using the '[[...]]' syntax. (Note that the first character of the expression following the initial '[[' must be different from '[', otherwise the expression will be interpreted as a field name. For example, '[[[a]' will be interpreted as a field named '[[a', this is similar to how that string is interpreted in a query. Using a space is safest: '[[ [length]/100 ]]'.) Expressions used in label text may not reference database components, this is similar to the limitations in the Expression transform templates. Invalid expressions are rendered as '***'.

The Style pane allows editing label text for label components using a specialized dialog with a query builder.

Rendering labels optimizes rendering complex whitespace.

Migrating labels bound to a drawing from Manifold 8 no longer creates a computed field with label text and instead just uses the label text pattern without any changes. (If, on a rare occasion, the text pattern includes '[[...]]' sequences, these sequences will currently have to be escaped manually to make the label text exactly what it was in Manifold 8. We might do this automatically in the future.)

The New Labels dialog allows editing label text when creating labels for an existing drawing.

The Info pane remembers the last used view options for the Coordinates tab on a per-window basis (map window / table window).

Attempting to write a text value into a GDB that is too long shows an error message with the name of the field, the maximum length allowed by the field and the actual length of the value.

Creating a new text field in a GDB sets the maximum length of that field to 4096 characters (was: 255).

Special fields in a GDB that cannot be edited (eg, Length / Area) are marked as read-only in Manifold.

(Fix) Attempting to open a damaged GDB no longer tries to read its structure, reporting multiple errors.

End of list.

There's a new video showing how easy it is to create labels using fields and expressions: https://www.youtube.com/watch?v=ypjvrYsKuZE

Nice. I really like the expressions for labels. Very powerful.

Many thanks for the video to introduce this Dimitri. I find these really useful as a launchpad for fiddling with new features.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

+1.

Labelling expressions can now also use CASE constructs (haven't tried it, but I believe so), as well as any math function, allowing conditional and responsive labelling--useful for data exploration, filter tuning, error diagnosis, other things.

Great idea, Tim. I tried CASE and it works:

Attachments:
case_labels.png

Although, I have to say that as fun and convenient as it is to be able to write darned near any expression in the labels text box, I can see how that could get out of hand in terms of hiding important logic within the label text construction.

With the new labels system there are two ways to get to the same result using custom computations: you can put the computational logic into a computed field and then use that computed field in the label text expression, or you can put the computation into the label text expression itself.

Suppose the logic of whether population is high or low is really important to grasping a cartographic display. There's a case (no pun intended...) to be made that such logic should be more exposed in the form of a computed field in the table, where it's clear there's a logical/computational process going on to generate information that's important enough to be displayed. If the logic is done in the label text expression, you have to look at the label style to see there's a computation going on.

There are some performance tradeoffs. Label expressions are computed mostly for what's in sight every time you pan or zoom. Computed fields in tables are computed just once for the whole table and stored, and are recomputed only if something in that record changes. So if it's a complicated expression that takes long computation it could be better to use a computed field, so that labels thereafter are faster.

It's still super to have the option of doing it either way. :-) I like the interactivity of just changing something slightly in the Style text box and seeing how things change. Good for data exploration.

Label expressions are indeed an excellent addition. As you say, it is nice having the option of doing it either way. That has always been one of the beauties of Manifold.

Consider applying this same capabilities to drawings. ESRI calls it a definition query, but of course it is limited by more basic SQL. In Mfd, we can write a query and create a drawing from that. Problem is that requires 2 more components cluttering up the project pane and hassles associated with creating indexes, mfd_id, etc. I recall being successful with the process in the past but also being frustrated with trying to get it to work.

Thanks for working on labels!

What is the "problem" here Mike?

Are you proposing to have drawings that are not based on tables?

Everything is a table. Indexes are good. User control is also good (and infinite).

What would you want to give up, to have canned food?

Yes, of course still all based on a table, just a slicker way to have a drawing display only the objects of interest. Rather than write a separate query that is complicated by having to handle mfd_id and indexes and also creating another drawing component, we could replace both of those with this new method applied now to just labels.

In manifold 8 a script (concat append) had to be done to change the textual content of the cells used to be displayed.

Now everything is done visually.

The style tab used for geom (point line area) now exists to format the text !

Manifold is getting more and more powerful graphically with wizards!

Manifold 9 is really SQL oriented and I realize that everything done using the GUI (creation, modification) is saved in a database! The large number of SQL functions makes it easy to understand the data structure and therefore to use manifold 9!

I am not a cartographer but as soon as I have time, I try to understand how this software works and how it evolves.

I wish there was a tutorial or video on how to create widgets which were already available in manifold 8. There is no longer any editor worthy of the name in manifold 9. However Roselyn has an intellisense system implemented in its core and when I see that python has a SQL editor ( color syntax auto completion) , I don't understand why manifold 9 is not a proper SQL editor ( i really like the SQL editor for search reserved word and name function but color syntax error ll be wonderfull ...) . In fact, I understand that those ( pro) who develop (web or desktop) must have at least Visual Studio and use typescript ! MAnifold should focus on SQL and Gis users !

I think that the database ( *.map) of Manifold should be accessible to other ORM ( need provider ) like the Entity Framework ( EF)

Translated with www.DeepL.com/Translator (free version)

Book about Science , cosmological model , Interstellar travels

Boyle surface fr ,en