Subscribe to this thread
Home - Cutting Edge / All posts - Manifold System 9.0.173.last
adamw


10,447 post(s)
#20-Apr-21 17:08

This thread describes the last batch of updates to the 9.0.173.x series of builds which were merged to 9.0.174.

The build can be downloaded from the Product Downloads page.

adamw


10,447 post(s)
#20-Apr-21 17:08

Changes

The map window supports the new Erase command in the context menu for editing geometry. The command allows erasing parts of areas, lines or points. The command shows a dialog which allows specifying the target layer, switching between erasing parts of all or selected records, and switching between keeping inner or outer part of the result. The default is to process all records and to keep the outer part of each. You can erase using new or existing area geometry. The command behaves similarly to other edit commands: processed geometry loses curves and Z values, last used options are saved in the map window, the operation tracks progress and can be canceled.

The 'Save update query' checkbox in the Join dialog is replaced with the 'Setup Join and Edit Query' button. Pressing the button prepares the target component for the join by adding fields or channels as needed, and then opens a window with the update query.

Switching cursor modes in a map window immediately updates the cursor. (Not waiting for cursor movement.)

End of list.

danb

2,064 post(s)
#21-Apr-21 04:28

The 'Save update query' checkbox in the Join dialog is replaced with the 'Setup Join and Edit Query' button. Pressing the button prepares the target component for the join by adding fields or channels as needed, and then opens a window with the update query.

This is a huge improvement to a very powerful tool. Hopefully you will keep adding to the join dialogue functionality in future builds.

Is there any chance that if the join requires adding attributes to the target that the ALTER TABLE query text be added to the update query text but commented out?


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

Dimitri


7,413 post(s)
#21-Apr-21 04:42

When you press the Setup Join and Edit Query button, it runs the ALTER TABLE part to add required attributes to the target. That's the "Setup" part.

tjhb
10,094 post(s)
#21-Apr-21 05:18

Yes... but is there a clear rationale for this?

I would prefer that the strict dichotomy be maintained, between what the GUI does and what auto-generated code does (or can do).

So, if I don’t execute the GUI command, but elect to press the <show SQL> button instead, why would I want side effects? There should be no side effects at all.

I would expect auto-generated SQL to include everything that the GUI would do, but not do anything until I asked it to.

A small design error perhaps. This doesn’t fit the established paradigm. Maybe there is a reason? I don’t think side-effects are a good plan.

(I think I am agreeing wholeheartedly with Dan, sticking my neck out slightly more .)

danb

2,064 post(s)
#21-Apr-21 05:58

Hi Tim, we are agreeing

I typically use the join dialogue to generate SQL that I then harvest, modify and insert into a longer workflow script for reuse.

I understand from comments made a while back (possibly from Adam in the forum or possibly in response to a feature suggestion) that Manifold want the generated SQL to be able to be run more than once (if necessary) without throwing an error.

This is fine but as things stand, I am forced to build the ALTER TABLE code manually to add to my workflow script despite it already having been generated and run in the 'Setup' part. Its a small pain but a pain none the less which seems avoidable.

Having it included but commented out seemed like a way to have the best of both worlds and as Tim points out, would better seem to fit the established paradigm.


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

Dimitri


7,413 post(s)
#21-Apr-21 08:25

Yes... but is there a clear rationale for this?

Sure. The rationale is to make it easy to do updates, repetitive joins.

For many people, the Join dialog is not a one time process. For example, every week they get a new report that has to be joined into the same drawing in exactly the same way, just using updated weekly numbers.

They do not have to alter the destination drawing every time, because the first time they do it, it is already equipped with any new fields that need to be added. After that, every week all they need is to update an already configured destination.

From the above, you can see that the first time you do the join entirely in SQL you need a different query than any subsequent runs. What is the best way to handle that, especially given the accelerating trend of people not reading user manuals?

The prior approach was to generate a query that had two parts to it: a setup part that was only valid the first time the query ran, but which blows things up when run in subsequent updates, plus an update part that was valid for both the first run and subsequent runs.

That resulted in a query text that ran OK the very first time, but which failed every subsequent time, and , unfortunately, it failed too often for too many people. Why? Because too many people don't read documentation and just would run it blindly without commenting out the one-time set up portion.

The new way, in contrast, always works. The query that is generated never fails, even in the hands of people who don't read documentation. It's a much safer approach.

It may, of course, alter the destination table by adding fields if that's part of the commanded Join, but it will never delete any fields or alter any of the data in the table. So it's a benign modification that's completely safe in that it doesn't alter or delete any data. It's just setting up the table for routine updates.

The task the button accomplishes is to generate a query that always works as an update query, both the first time and subsequent times. The task is not to generate a query that does a one-time alteration to a table, but which then fails every other time you run it.

I suppose the query could be modified to add the setup portions but have them commented out. But there are advantages and disadvantages to that. The only advantage I see is that it writes a query that if somebody wants to use it, it will only be used one time by uncommenting the setup part, and then after that it will be wrong unless the person remembers to remove that setup part.

The disadvantage of that is that it confuses people who don't understand commenting out query text, and who expect just to see an update portion. Another disadvantage is that it risks reviving the problem of less careful people having queries fail on them, if they uncomment and try to re-run the setup part. I agree that's likely to be less of an issue, but it's something to consider.

danb

2,064 post(s)
#21-Apr-21 23:33

I see your reasoning, but still think that it doesn't quite fit with the design philosophy of other parts of the program.

For example Transforms. You are offered 'Edit Query' or 'Transform'. If I wanted to blindly press buttons, I would always hit 'Transform' (or use ESRI/QGIS with all the limitations that that brings). In contrast, I would think that the minimum standard for choosing 'Edit Query' button is either a basic knowledge of what the query is doing, a desire to understand what it is doing, or to use a knowledge of SQL to edit and adapt it for a subtly different purpose.

This would seem to be the same with joins except 'Transform' becomes 'Join' and 'Edit Query' becomes 'Setup Join and Edit Query'. The latter is subtly different I agree, but the 'Edit Query' bit still implies that you know something about what it is doing and may have the skills to edit the query text (hopefully) without rendering it useless.

Perhaps the problem is with the way I personally think of Manifold (which applied to both M8 and M9). The beauty and power of it is that it does require the user to have at least some understanding what they are doing. This knowledge turn means a Manifold user can achieve tasks that an ESRI or QGIS user could never hope to complete, efficiently, in one application with metadata about the process.

Anyway, we will probably have to agree to disagree. Being able to adjust the query text BEFORE running it is a huge step forward which (with a bit of SQL knowledge) nicely circumvents some limitations of the join dialogue in its present form. Many thanks for this


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

adamw


10,447 post(s)
#21-Apr-21 10:12

Will add my reply here.

There are pros and cons to including the setup portion in the query, as Dimitri said. The pros: (a) pressing Edit Query does not alter anything at all, (b) you can copy / paste the setup portion into your queries if you want. The con: (c) in most cases you want just the update portion of the query anyway, removing the setup portion makes this most frequently happening scenario easier.

The reason we switched away from the checkbox that was going even further in the direction of (c) is that we wanted to have an option to avoid running a potentially long join, giving a chance to adjust it manually first. This also had a hidden plus in that the button for generating the query works even for read-only data sources, whereas the checkbox for saving the query did not (cannot save the query if you don't have write permissions for the database -- normally you cannot run the query either, but you can at least look at it, copy / paste into a different project, etc). We might rework the button into the traditional Edit Query button we use in other places and include the setup portion in the query in the future.

What would have been ideal is if we had means to skip the setup portion automatically in the query if the setup was already performed. But that seems kind of difficult to even check for. (Added: actually, maybe it isn't.)

Mike Pelletier

2,122 post(s)
#21-Apr-21 18:19

The new Erase command is a very nice addition. To help infrequent users keep track of how Erase, Clip, and Split work, consider changing the title for the dialogue that pops up after clicking on one of these commands. There is plenty of space to be more descriptive. Something like "Erase objects in ...", or be more descriptive "Clip edited geometry using objects in ...", or "Split objects in specified layer".

Adam posted this excellent synopsis of the new editing tools and perhaps it should be added to the Context Help.

Editing:There are new commands for editing vector data. Clip trims the edited geometry to objects in the specified layer, keeping parts that are either inside or outside of the objects. Erase deletes parts of objects in the specified layer that are either inside or outside of the edited geometry. Merge combines the edited object with other objects in the active layer, merging field values according to user-specified transfer rules. Split cuts objects in the specified layer into parts using the edited geometry as a cutter line, producing new objects and splitting field values according to user-specified transfer rules.

Dimitri


7,413 post(s)
#22-Apr-21 11:45

There's a new Erase topic, as well.

Mike Pelletier

2,122 post(s)
#22-Apr-21 16:26

Great. Must say that I'm jazzed about the flexibility of the new editing tools. Seeing CAD drawings in the help topics, makes me even more excited about what is coming. I use Canvas for CAD design work and get my ideas on what Mfd should be able to do from them. Good drawing tools really opens up lots of uses and helps keep the job more fun. Keep going!

LeRepère
153 post(s)
#22-Apr-21 18:24

It's this kind of recurring tool that increases the interest in working with M9.

adamw


10,447 post(s)
#08-May-21 15:58

A short status update:

We will issue 9.0.174.1 next week. There is a fairly big feature plus a lot of small improvements in various places.

adamw


10,447 post(s)
#17-May-21 15:15

A follow-up:

The build is going to take a few more days. It is pretty much complete apart from a single issue which we are working on (Unicode is hard).

Thanks for your patience.

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