9.0.166.3

manifold-9.0.166.3-x64.zip

SHA256: ddf95dc7754119541660cbf077e72050cafa57b0c2cd7c06337d52195448379e

manifold-viewer-9.0.166.3-x64.zip

SHA256: 6387424ca29298edd2f950dd88f6a6218cbf383502cd14884b7f7d104bd03e4f

Changes

Invoking Help - Documentation opens the user manual instead of the page that contains a link to it.

Pressing F1 in a comment or script window opens the keyboard reference for that window.

Queries representing database views report their schemas. The Project pane allows viewing the schema of such a query by right-clicking it and selecting the Schema command.

Queries for the Manifold query engine report their schemas as long as the schema of the result table can be discovered without running the query. (Example 1: SELECT * FROM t WHERE ...; - the schema of the result table can be discovered without running the query. Example 2: CREATE TABLE t (...); SELECT * FROM t; - the schema of the result table cannot be discovered without running the query.)

The New Drawing dialog allows creating a new component based on a query, as long as the query can report its schema.

The New Image dialog allows creating a new component based on a query, as long as the query can report its schema.

(Fix) The New Labels dialog correctly handles creating a new component based on a drawing based on a query.

The New Drawing and New Image dialogs disallow adding spatial indexes to tables which do not support altering table schema (eg, read-only).

The New Drawing and New Image dialogs no longer list system tables (MFD_xxx).

Creating a new component on a data source which adjusts names of created components (commonly seen with databases which prepend schema name) captures the final created name and correctly selects the created component in the Project pane.

(Fix) Dropping a query into the query builder no longer runs it to determine the schema of the result table. (This was a misfeature.)

The DB2 dataport reports schemas for materialized views.

The Oracle dataport treats materialized views as queries, not as tables.

The PostgreSQL dataport allows accessing materialized views and reports their schemas.

The SQL Server dataport tries to resolve the SRID of geometry values in a table to the system MFD_SRID table (composed based on a SQL Server view). If the SRID cannot be resolved, it is interpreted as an EPSG code, according to the Microsoft guidelines and similar to how these codes are used in practice by Manifold 8 and other products.

Dataports for SQL Server and other databases map unrecognized field types to NVARCHAR. (This allows working with partial data in tables that contain fields which the database driver cannot work with - usually due to a bug, a misconfiguration, or a version skew.)

(Fix) Reading a CTG file no longer sometimes creates an incomplete coordinate system.

(Fix) Reading a MIF file no longer sometimes creates a wrong coordinate system.

Exporting vector data to DXF, GDB, MFD, MIF files (in addition to E00 and SHP which were done earlier) clears the values of the local offset and local shift values in the exported coordinate system and forces the axis order to XY.

Linking an isolated GCDB DAT file for a single state no longer creates the 'API' comments component with the list of supported geocoding functions (because geocoding functions require linking the full GCDB data set, not a single file).

Sorting records in a table window requires Ctrl-clicking the field header instead of just clicking. Shift-clicking the field header continues to add the field to the current sort order.

Rendering a label bound to an area tries to places the label into the middle of the visible portion of the area.

The advanced rendering engine supports rendering labels with shadows. The basic rendering engine scales label shadows during printing (were frequently invisible before).

The advanced rendering engine supports rendering labels with halos. The basic rendering engine scales label halos during printing (were frequently invisible before).

The advanced rendering engine supports strikeout and underline font options.

End of list.

Rendering a label bound to an area tries to places the label into the middle of the visible portion of the area.

Works great, thanks for the feature!

The "tries to" bit is because of the reactive placement of labels. If the entire area is in view then the label goes into the center, but as you pan and zoom the labels are placed on the fly to try to fit into what is available.

A view of provinces in Mexico, labeled by name, zoomed in to Jalisco. Jalisco's label is centered, as is Aguascalientes's label. But others, like for Durango or San Luis Potosi, are automatically moved off center to near the edges of the province that appears in the view.

As you pan the view, the label for Zacatecas automatically drops down to stay in view, and the label for Michoacan moves to the left. There is more tuning planned, of course, with more controls coming, but already it is useful.

Attachments:
mex1.png
mex2.png

Reactive label placement will be handy, I didn't test extensively but it seemed there were less issues in my map with many small areas, when I zoomed out, the labels in M9 seemed to position themselves to maximize the number of labels visible. In M8 at some level of zooming out some labels would start to drop off so as not to be stacked on top of each other. To some degree I could manually move my labels in M8 to find a solution that showed as many labels as possible. Will be interesting to see how M9 handles labels. Are (reactive) call-out lines in the works?

Are (reactive) call-out lines in the works?

Yes. As well as improvements to the label placement algorithms.

A quick note if you create drawings from queries. For now, those appear only if shown in a layer with some other component that provides a bounding box context.

Example:

1. Using the sample Mexico project, create a query called Query that contains:

SELECT * FROM [Mexico Table];

2. Right click on Query in the project pane, choose Create - New Drawing, create a drawing based on the query called Drawing.

3. It knows to use the Geom field that the query produces. Set the coordinate system to Lat/Lon (what the default Mexico example drawing uses) and create the drawing.

If you open the drawing by itself, nothing appears. However, if you create a map, drop in a layer like Bing Streets as a background, and then drop in Drawing, then it will appear.

We'll get this sorted out so the drawing by itself will appear without needing some other layer for context. For now, just use such drawings created from queries as a layer in a map with other components.

I send a suggestion but discover and test again that i was wrong ( no problem , only my way to use manifold was wrong ) . So Label can't be create against Drawing using another Geom column or use table with geom column. So to apply transform ( shift offset move translate rotate ..) for change the default label location ( center of area /line/point ) we need to create a drawing that ll be use fort create a Label component .

Then when we apply transform rotate the drawing that manage in a way the label location only the label attach to <geom line > orientation change ... not label attach to point or aree ( the center of area don't change during rotation) !!

regard's

join image "Because my dad promised me" interstellar from Manifold: Time by Stephen Baxter. power Math destruction

Drawings from queries was probably the most powerful thing that manifold 8 had. For me, it was my bread-and-butter, go to thing. One thing that I really liked was that if I changed the query I could simply refresh the drawing. I don’t like the fact that I have to run the query, and then open the drawing and refresh it. Hopefully in the future, simply refreshing a drawing will show any changes from the underlying query from which it is based.

I don’t like the fact that I have to run the query, and then open the drawing and refresh it. Hopefully in the future, simply refreshing a drawing will show any changes from the underlying query from which it is based.

Hopefully, no, maybe not exactly like that, since we don't want to repeat the mistakes 8 makes in such things. :-)

First, an aside: in 8 if the drawing were closed you would have to open it as well. Same in 9.

In 9, refreshing a drawing gets the latest results from a query.

If you change the text in the query, you have to run the query at least once. Thereafter, whenever you refresh the drawing then you get the latest results from the query with no need to re-run the query.

That is different from 8 but the way 8 did it was sometimes a big mistake. It is an example of something done for you automatically that often is OK but sometimes is wrong. It is also an example of something that when it is wrong it can be very, very wrong. When you consider ways to avoid the mistake that 8 was making, the 9 approach is actually a pretty good way to avoid that mistake.

It boils down to the difference between itty-bitty data and big data. With itty-bitty data you don't care if a *new* query is run for you whether you want it to be run or not, because the thing runs so quickly you are not inconvenienced. But with big data a knowledgeable operator usually does *not* want software insisting - whether you like it or not - to run a new query for you. Why? Because maybe that big query will take five minutes or five hours to run, and right then you don't want the system to get busy on you.

In most circumstances when you change query text you don't do so unconsciously (might happen unconsciously if you have a program or other process re-writing queries without you realizing it, but that's a different matter...). You pop open the query and you edit it to change the query. Pressing the ! bang button when you're happy with the edit is just one more click, just like pressing Enter or the spacebar. It's no big deal, but it does save you from having the system decide to run a huge query whether you like it or not. For example, suppose that linked drawing was left open on your desktop, you've edited the query and then... what? the query runs whether you want it to or not?

If you are working with itty-bitty data, where having the system run new queries whether you want them run or not is a "don't care," well, then in that case hitting the ! bang button at the end of an editing session is also a don't care. One click and done. But if you are working with big data, well, in that case having the control over whether you want that query launched right now or not is a very big deal.

After all, maybe you have other work you'd like to be doing and don't need to pop open the linked drawing just yet, or maybe it is open and you want to move it or to close it without the system running the query to update it, or maybe you want to change style while the whole thing is in sight before the new, edited query removes part of it. When you judge the time and place is right to run the query, well, then you right click the changed query and click on the ! command.

It's true, of course, that the price of greater capability and avoiding mistakes from automation is that if you don't run the query at the end of editing it, but instead defer running it and then forget to do so, well, the linked drawing won't show what the edited query produces. But that's a nuance. For now, just remember to do it. As 9 brings in endless small conveniences that is one that could be added, where linked drawings check if their originating query has been run since the last edit and, if not, prompt a run or whatever.

Just tossing out a few considerations that 8 didn't reckon. The 8 way of insulating users from the downsides of such considerations was to make it unpleasant to work with big data in the first place. :-) That's kind of a blunt force trauma approach to user interface subtleties. 9 does better, by not only enabling use of big data but also striving to make big data safe and convenient.

Thanks. But 8 didn’t rerun a query whether I wanted to or not. Linked Drawings required me to refresh the drawing. That is all I was thinking, that if you refresh a linked drawing, it would refresh the drawing based on the text in the query.

Now, I see your point with .RefreshAll when maybe one linked drawing is really large, but we had to deal with that in 8 as well

But 8 didn’t rerun a query whether I wanted to or not.

It did, it just didn't tell you explicitly. 9 just makes that an explicit step.

Perhaps a useful option to add to the "New Drawing" dialog: a boolean flag indicating whether the component should also re-run the underlying query in order to refresh itself when requested by a Drawing component refresh request?

Do the "Active Columns" in Release 9 refresh themselves automatically? If the column's expression creates geometry from some other data in the row, and those other data change, the geometry is "immediately" updated, regardless of the computational cost of that expression. A Drawing component that might be using that "active" column still needs to be "manually" refreshed to be displaying that newly updated geometry, right?

I know, they're not "active" columns anymore, are they? I'll update my nomenclature soon enough here.

Do the "Active Columns" in Release 9 refresh themselves automatically?

Do you mean in tables? Or drawings? What happens when you try? :-)

Art's comment and computed fields are very closely related but different in a key detail: you can open a query to edit the text of that query, but when you add a computed field to a schema you cannot thereafter open the schema and edit the expression for that computed field. So there is no question, as Art raised, about having to run the query at least once, that is, having to "run" the computed field at least once.

By the way, if you want to change the expression used for a computed field does you must delete the old computed field, and then add a new computed field with the expression you want.

A side effect of 9's allowing field names to linger in things like queries, etc., is that you could in many cases do the above and just use the same name for the new computed field. That would have the same effect as if you could edit the expression.

I know, they're not "active" columns anymore, are they?

No, they are "computed fields." See Example: Add a Computed Field to a Table

Do the "Active Columns" in Release 9 refresh themselves automatically?

My needs are usually fairly simple. I have a parcels table with a new computed field to calculate acreage based on the square footage in the area (using RoundDecs(GeomArea([Geom (I)],0) / 43560, 3) ). When I change the shape of an area and Update Record, or add a new area, the computed field updates automatically.

see my post about active column / computed Field here

join image "Because my dad promised me" interstellar from Manifold: Time by Stephen Baxter. power Math destruction

Do the "Active Columns" in Release 9 refresh themselves automatically?

Yes. The value in a computed field is refreshed when you change values in the fields that the expression in the computed field depends on. (Ie, if a computed field B is set to be A+100, then when you manually edit A, the system automatically computes B - right at that moment.)

One thing that I really liked was that if I changed the query I could simply refresh the drawing. I don’t like the fact that I have to run the query, and then open the drawing and refresh it. Hopefully in the future, simply refreshing a drawing will show any changes from the underlying query from which it is based.

I am late to the thread, sorry.

It is not so much that you have to run the query before refreshing the drawing, it is that you have to save changes you made to the text and running the query is a typical way to do this (which also allows you to see if there are any errors). Closing the query window would have saved it just as well.

8 has been saving the query text automatically after each change. We cannot do it exactly like this in 9, because in 9 the query can be on a database, and if so, saving after each keystroke is too slow and produces a lot of unwanted traffic (and has to resend full query text every time). But we don't have to do it exactly like 8, we can do plenty of smart things to both save automatically and not flood the database with intermediate changes. We will do this and then you will be able to edit the query and refresh the drawing immediately after.