Subscribe to this thread
Home - General / All posts - Manifold Future Wizards
dchall8
341 post(s)
#12-Oct-17 00:11

Are wizards in the future for 9 or are we going to have to become our own SQL wizards? Here's what I'm talking about.

I need to have meaningful labels for the areas in my map. The wizards in Manifold 8 make it fairly easy to create them. Mine need to be 3 lines deep and located in the centroid of the areas on a live basis for when the areas are split into pieces. In 8 with a couple of clicks I can change the font color using the labels toolbar. And I only want to see the labels when the area is selected. In Manifold Future it looks like the labels are currently limited to one line, font cannot be formatted, and locating them at the centroid is a separate process requiring a redrawing of centroids with every area split. And I can't find a way to add a field with a Boolean switch for selectedness.

But before I can do any labels I have to have the correct information in the table fields. When I opened the 8 map file the fields on the related table did not come through. So now I need to figure out how to relate the area table with the data table. Again, the wizard in 8 makes it easy to relate the table to the drawing.

One of the fields in my labels is acreage. I did figure out how to make a new field for area and how to make an active field converting area to acres. For me this was a wildly satisfying achievement. Now how do I round the decimal places down to 3? I'm looking at RoundDecs(<value>,<decimals>):<value>. I tried RoundDecs([WorkingParcels Table].[Acreage],3):Temp, but it did not like my Invalid object reference. I'm not certain what part of that is invalid, but I am frustrated enough to write and ask.

Also in 8 it is easy to update the calculated fields in the table. I don't see how to update it in Future.

Is there a way to save queries to the Project pane?

How can I reuse queries from Manifold 8? They need to link to a table.

rk
216 post(s)
#12-Oct-17 05:41

Call the fn like this.

RoundDecs([WorkingParcels Table].[Acreage],3)

The thing after colon indicates return type of the fn, not part of fn call syntax.

dchall8
341 post(s)
#12-Oct-17 14:14

Invalid object reference again.

Dimitri


4,332 post(s)
#12-Oct-17 15:00

Invalid object reference again.

Way too much information. From the above it's not possible to respond with anything but "You are doing something wrong again." It would be more productive to be able to state precisely what is being done wrong and how it should be corrected.

If you want people here to help you find the errors you are making, you have to tell them every last detail of what you do, such as the *entire* text of your query, along with a complete schema for every table involved. That's required to find things like spelling errors in field names, incorrect syntax that leads to referring to things that don't exist, etc.

I would also strongly, firmly urge you to take the advice that, I believe, has been offered many times in this forum: choose a transform template that is similar to what you want (see, for example Round to Decimals in the Transform Templates - Numeric topic) and press the danged Edit Query button to see a fully complete SQL example of how to use a particular function of interest. After you read that example and understand it perfectly, perhaps by making a few changes to it to see what those do, then go and write your own queries from the ground up.

After all, if you have a wizard ready to write SQL for you, why not use it? :-)

dchall8
341 post(s)
#12-Oct-17 19:10

Here's the entire text of the query...

RoundDecs([WorkingParcels Table].[Acreage],3)

Schema is attached. Is there supposed to be more to it? I do have a query from 8 to reformat several columns in one pass. I'll look at that to see if I can make it work in Future. No need to continue down this path until I've dug deeper into it.

In Manifold 8, as you know, you can right click on the field heading and format just about everything about how the numbers look in the table. I usually set to decimals showing 3 decimal places, default negatives, separate thousands, and right align. Then when I have the ViewBots showing with total acreage, the ViewBot sums all the computed acreages and compares to the acreages in our appraisal system to find large discrepancies.

I do recall seeing something about how the templates write code. I was not a Radian owner until this week, so there's a lot I've overlooked or not been able to try until now. I have a feeling I'm going to spend the afternoon clicking on the danged Edit Query buttons to learn how they work. Ground up probably means something different to me than what you intend. I'm thinking hamburger...which is how I feel after trying to get SQL to work. But I am willing to learn, so here goes.

Attachments:
Schema.jpg

Dimitri


4,332 post(s)
#12-Oct-17 20:36

Is there supposed to be more to it?

Yes. A function by itself is not a query. You don't need much more but you do need some. See what the edit query button does for the analogous transform template and you'll see what I mean.

I strongly recommend you get a copy of one of Chris Fehily's first rate books on SQL and cruise through it. SQL is not the least bit hard but you do have to honor what few demands it makes in terms of observing syntax. Chris is a great writer and has a knack for explaining SQL clearly and practically in the shortest way. He'll have you up and running in no time, with you thinking at the end, "wow, that was way easier than I thought..."

Note that you can use features in the Command Window to evaluate expressions without writing full SQL. It's a very useful feature, but there too you have to honor the syntax, like using the ? command to evaluate an expression. The SQL Functions topic uses that to show short snippets of examples without writing full queries.

Likewise, the transform dialog's Expression tab allows you to get away with writing expressions that are not full SQL queries, because the Expression tab helpfully surrounds them with necessary infrastructure. But don't confuse such short cuts with writing a real query.

By the way, one reason full info is necessary is because it is easy to overlook something simple, like a typo.

In Manifold 8, as you know, you can right click on the field heading and format just about everything about how the numbers look in the table. I usually set to decimals showing 3 decimal places, default negatives, separate thousands, and right align. Then when I have the ViewBots

More formatting for tables will get added as we cycle through formatting for tables. I love ViewBots too. I'd like something analogous to them to be in 9 as well.

Dimitri


4,332 post(s)
#12-Oct-17 14:48

A lot to discuss here...

Are wizards in the future for 9 or are we going to have to become our own SQL wizards?

There are very many wizards already there, in the form of transform templates where you can click the "edit query" button to have it write SQL for you (very wizardly...).

If you prefer something more free-form than the SQL the system writes for a template, use the query builder.

I need to have meaningful labels for the areas in my map.

Labels are still at Radian level, not where they are going. Keep your finger on the pulse of changes with Future. As formatting adds labels there will be far, far more capabilities with labels.

I have to have the correct information in the table fields. When I opened the 8 map file the fields on the related table did not come through. So now I need to figure out how to relate the area table with the data table. Again, the wizard in 8 makes it easy to relate the table to the drawing.

I don't quite follow the above but in general Radian / Future / 9 has far more capabilities than 8. There is no such thing, by the way, as an "area table" that is different from a "data table," so I don't understand what you mean by that. Everything is a table. A drawing is a viewport into a table. If there are any fields you can work with in a query using a drawing's name, those fields are in that drawing's table.

Also in 8 it is easy to update the calculated fields in the table. I don't see how to update it in Future.

Future automatically updates computed fields. I note that "calculated field" is not Manifold terminology. The right term is "computed field." Use the precise terminology so you can follow along with examples and report exactly what you've done in the forum.

You can add a field that has set field values, and you can do something related, but different, which is to add a computed field. There are two examples that show the difference:

Add a field to a table and fill it

Add a computed field to a table

If you just added a field to a table and filled it, but did not create a computed field, well, there is nothing to update because you've just filled that field with static values, not computed values. It's an ordinary field and will have white background. If you created a computed field as set forth in the second topic above the field will have a light gray background because it is not editable... the values in there are computed based upon some expression.

Is there a way to save queries to the Project pane?

Queries you create in the project pane are automatically saved. See the "to create a query" list of instructions at the very top of the Queries topic.

Do you mean, is there a way to save a temporary query that I wrote in the Command window into a query component in the project pane? Yes, of course:

Copy the query text. Create a new query in the project pane using whatever name you like. Open that query and paste the query text into that query. Done. As noted in the Queries topic changes made to query components are automatically saved.

As advised in the Queries topic, the usual way to create a new query is to create a new query in the project pane, to open the query and then to go forth and write whatever SQL you want in that query. But if you didn't do that but instead just launched the Command Window in an ad hoc way, no problem. Copy whatever SQL you've written and paste it into a query component.

How can I reuse queries from Manifold 8? They need to link to a table.

Open the query text and re-write it for Radian SQL. Depending on the query that can be trivial or it can be significant.

They need to link to a table.

Not sure what you mean by the above, as queries are operations on tables, so they all link to a table. Could you describe with more detail what you had in mind?

dchall8
341 post(s)
#12-Oct-17 23:54

Thank you for the reply. As for wizards, I prefer something where the options are already built into a dialog box, a la Manifold 8. For example if I want to format the text or numbers in a field, I can right-click the field name, select Format from a context menu, and make a few selections in a dialog box type of wizard. Other wizardly methods in Manifold 8 need no dialog box. If I want to sort a table based on a field I can click or shift-click on the field name. If I want to rotate a mapped object I can select the object and use the tools at the bottom of the window to rotate. If I want to number 5,000 parcels by a factor of 3, from south to north, it's only a few clicks. So I guess my question is will Future have dialog box or the intuitive types of transforms? If I have to program my own wizards, I'll likely stick with version 8. It's not as fast as Future, but it does what I need with no big learning curve.

On my other question, I lost you in the same place two times - must have been my wording. In Manifold 8 I use the Table Menu > Relations to connect two tables using a key field. One of these tables is my map parcel drawing table; the other is information table from our office computer. The map parcels table holds the geometry, a property identification code number (PID), and three other fields I have created. Two are scribble space for use on the fly. The other one is a computed acreage field. All the important information about the parcels comes from our office database. Once a week I query the office database to get a subset of data needed for the maps. I take that data through Excel to a .xls file. Then import the .xls to 32-bit Manifold, copy, and finally paste into 64-bit Manifold. Then I "relate" that table to my parcel map using PID as the key. This last step is what I'm trying to do here. I understand 'relate' as it applies in Manifold 8, but I don't see a template for it in Future.

adamw


7,307 post(s)
#27-Oct-17 08:50

A late reply:

Yes, we will have formatting for field values.

We already have sorting in cutting edge builds, including on multiple fields.

We allow rotating an object from the Transform pane (the Rotate template).

We don't have a specialized UI for relations, these are done using queries. Instead of using a dialog to add a relation from table P to table Q on shared field F, you write a query like:

--SQL9

SELECT * FROM P INNER JOIN Q ON P.F=Q.F;

...and operate off that table. In this particular place we did not carry over a feature from 8 because the design was a bit awkward (bringing fields from one table to another like 8 does has to make tons of assumptions and allowances - ie, what to do if a key value for a particular record matches more than one record? different scenarios call for different answers... there are also multiple valid ways to go when editing values brought from another table or when editing the values of shared fields, with the feature forcing a single choice) and there is a replacement feature which is only a bit more laborious to use (the initial query above is very simple) and is much more flexible (you can augment it easily to do things like summary records, reject matches based on values of non-key fields, etc).

dchall8
341 post(s)
#02-Nov-17 13:45

How do you undo a join like that? The beauty in 8 was that in less that 5 seconds I could undo last week's relation table and redo it with this week's updated table.

Dimitri


4,332 post(s)
#02-Nov-17 16:21

I could undo last week's relation table and redo it with this week's updated table.

I'm not sure I understand what you mean. Instead of an "undo" don't you mean you could just update the table with this week's data? You could do that in Future as well.

If you could give a specific example with step by step workflow we could talk about how, exactly, you would do that now.

dchall8
341 post(s)
#03-Nov-17 22:00

Maybe you have a better word than undo.

Undo a table relation In Manifold 8:

  1. Put focus on the drawing table which has been previously related to a second table.

  • Menubar>Table>Relations
  • Highlight the current relation

  • Click the red X in the Table Relations Tools

    That process brings me back to a pristine drawing table to which I can relate to the most recent data table from our master database. After you do it a few hundred times it goes very fast. Downloading the table and processing it through Excel and Manifold 8 (32 bit) takes the longest time.

  • tjhb

    7,545 post(s)
    #04-Nov-17 01:18

    Perhaps the answers here are becoming more complex than they need to be. I think you were perfectly clear when you said

    In Manifold 8 I use the Table Menu > Relations to connect two tables using a key field. One of these tables is my map parcel drawing table; the other is information table from our office computer. The map parcels table holds the geometry, a property identification code number (PID), and three other fields I have created. Two are scribble space for use on the fly. The other one is a computed acreage field. All the important information about the parcels comes from our office database. Once a week I query the office database to get a subset of data needed for the maps. I take that data through Excel to a .xls file. Then import the .xls to 32-bit Manifold, copy, and finally paste into 64-bit Manifold. Then I "relate" that table to my parcel map using PID as the key. This last step is what I'm trying to do here. I understand 'relate' as it applies in Manifold 8, but I don't see a template for it in Future.

    So let's imagine one table called [Parcel geometry], with fields [PID], [Geom], [a], [b] and [acreage]; and a second table called [Parcel data], with fields [PID], [x] and [y].

    In Manifold 8 you would open [Parcel geometry], choose Table > Relations, add a relation on [PID] -> [PID], and check [x] and [y] to "borrow" those fields from [Parcel data]. To refresh the relation for new data, you would delete the defined relation and start again.

    To implement the nearest equivalent for Manifold Future/9, following Adam's suggestion, you would use File > Create > New Query, and give it text like this (with adjustments for actual names).

    SELECT [t1].*, [t2].[x][t2].[y]

    FROM [Parcel geometry] AS [t1] LEFT JOIN [Parcel data] AS [t2]

    ON [t1].[PID] = [t2].[PID];

    Run the query. At a first approximation, that's all there is to it.

    When you have a new version of [Parcel data], just run the query again. There's nothing to undo or redo--the only thing to check is that the name or [Parcel data] has not changed (adjust the query text if necessary).

    (You could also incorporate automatically calculating acreage here, but let's leave to one side.)

    You will probably also want a drawing that shows the data from this joined table. That's slightly more complicated but not difficult.

    artlembo


    2,916 post(s)
    #04-Nov-17 19:56

    that is good advice, and a cool way to create a sort of VIEW inside of MF. However, and I could be wrong, in doing this we can see the new drawing, and even symbolize the drawing, but I don't believe we can issue an Alt-click to get information on the drawing. I think this is due to the indexes not coming over in the query. Any thoughts on how we can use the info tool on this?

    tjhb

    7,545 post(s)
    #04-Nov-17 20:56

    You are exactly right Art.

    The join above converts the BTREE on mfd_id in the left table (Parcel geometry) into a BTREEDUP, as it must. (An inner join would do the same. The reason for the 'must' is that the compiler needs to know the schema, including indexes, before it processes the data. Because duplicates can occur, it must work on the basis that they might.)

    A BTREEDUP with no BTREE means no selectiing objects.

    There's not much we can do about this, using just the joined result.

    An aside:

    It seems worth noting that if the query table had no RTREE, and we tried to make a drawing based on it, we'd get a message, with the option to create a temporary RTREE on the query table to allow the drawing to work.

    Perhaps something similar could be done where the query table has no BTREE--again a message, and an offer to create a temporary BTREE on a field in the result table, although the attempt would have to fail if the chosen field did not contain unique values.

    End of aside.

    What we need to do here is create a new static table, with a defined BTREE index, using either CREATE TABLE... INSERT INTO..., or SELECT INTO... ALTER TABLE....

    Second aside:

    Which in practice is currently slightly tricky. If we know that values in mfd_id are unique, after the join, then all well and good. Sometimes we do know, but this is data dependent. (Here it depends on whether any row on the left can potentially be matched with multiple rows on the right. If FID is unique in both tables, then we know there will be no multiple matches, and mfd_id in the result must be unique.)

    It values in mfd_id are not unique after the join, or we don't know, then we will want to exclude mfd_id from the projection into the new table. That is, instruct CREATE TABLE to add a new mfd_id field, and a BTREE index on it, but leave out the source mfd_id field from the INSERT INTO, so that the new field will be filled automatically with unique values (and the index handled accordingly).

    A side effect is that we need to know, and list, all the source fields that we want, to exclude mfd_id. That's OK, it just limits what we can do generically by SQL alone. Which is just to say that a generic, bulletproof approach requires a script. OK.

    There is the earlier discussion about being able to exclude mfd_id (or other named fields) from the projection list by some new syntax. That would be good, but again there is a possible wrinkle that gets in the way of doing things generically.

    What if there is no mfd_id field in the source table(s)? This can be true for example for data imported from SQLite/GPKG, where the source FID field is used instead, and no mfd_id is created. Perhaps the proposed new syntax could exclude named fields if they exist, and ignore the exclusion(s) otherwise? That would be fine I think.

    (I have been thinking about these topics a lot in the last few days, a bit of thinking out loud here.)

    End of second aside.

    I'll post the code we need here (for now) in a moment.

    Dimitri


    4,332 post(s)
    #04-Nov-17 09:28

    Thanks for the explanation!! That clears things up. I think I had trouble visualizing the situation for two reasons:

    1. "Undo" usually means a specific command, typically launched with a Ctrl-Z, for example, that rolls back something that was done. I didn't understand you meant that to refer to deleting a relation from a table and then adding a relation again. So I was running around looking for an "Undo" command in 8 for relations that for the life of me I could not remember being there... :-)

    2. I was slightly surprised by this in Tim's post: " To refresh the relation for new data, you would delete the defined relation and start again. " - For some reason I thought that bringing data into a Release 8 table from an external source via a relation could be / would be refreshed without having to delete the relation and adding it again.

    But... the above is why it helps to ask for clarification! :-)

    Tim's right, by the way: the ability to just re-run the query in 9 is much, much better than having to manually delete a relation and add it again in 8.

    dchall8
    341 post(s)
    #07-Nov-17 21:42

    This gets us back to the original question about wizards in 9 like there are in 8. Lets say that rerunning the query in 9 is better. I have 30 or more fields to join. In 8 it needed no separate query. I could relate tables as fast as I could click and get all the fields from each one. With 9 each table needs a custom query which is not intuitively obvious to a SQL plebe like me. I use Manifold to keep track of parcel ownership in a mapping environment - not as a tool to learn SQL.

    The Manifold 8 Toolbars are golden. The simplicity and power of the Query and Transform Toolbars is immensely helpful. I can do things really fast that my ESRI user friends cannot do at all (because they have not gone to that training). Those toolbars are always on at the bottom of the window, so I don't have to think about the process for finding the Transform pane. Secondly they automatically switch modes depending on whether a table or map is in focus. Third, most of the references in the Transform menu are understandable. In 9 it is often very cryptic (e.g. Parse GeoJSON, bounds, branch, Compose Point, copy (but no paste), etc.)). I can't imagine how many lines of SQL (that I don't have to learn) are buried in the 8 toolbars, and I appreciate it.

    I know about RTFM, but I already read much of the FM in 8 to get where I can use it. I was hoping 9 would not be a complete rewrite of the user interface. Using one interface for 13 years gives a person confidence and speed. So far 9 has different menus, mouse buttons, keyboard keys, and toolbars. What is the motivation to change every aspect of a program that is just the next version? That's what ESRI used to do. I was hoping 9 would be the same old Manifold we have come to love but with some tune ups made possible by the Radian Studio technology. I do like the ability to undock a window or table, but I don't like the inability to use mouse and kbd combinations to deselect background elements I have accidentally selected while trying to select a line.

    I realize I am expecting too much too soon with 9. I guess I'm worried that the current enthusiasm for the SQL abilities is going to overshadow the ease of use I've grown up with.

    Dimitri


    4,332 post(s)
    #08-Nov-17 09:19

    You raise so many good points, in good faith, let me try to address them. This is not intended in any tit for tat way but rather to try to open up the discussion to perhaps show that what you want is there before you.

    It is there in a different way, of course, which is the usual learning of new and improved methods which open the door to greater capability. Zipping about in a sports car really is faster and covers more ground than trotting on a horse. But as much fun as trotting on a horse may be, the skills which enable one with confidence to cover ground on a horse are fundamentally different than those required to drive, say, from San Francisco to Ensenada in a day, covering huge mileage on Interstate 5 and successfully punching through LA traffic en route.

    I use Manifold to keep track of parcel ownership in a mapping environment - not as a tool to learn SQL.

    That is a bit like saying "I use my sports car to get from San Francisco to Ensenada, not as a tool to learn how to work the steering wheel, the gas pedal and the brakes." Well, sure. Likewise you use Future as a tool to get tasks done, not to learn SQL. For that matter, you con't need to know SQL to drive Future, no more than you need to know how to work a clutch and manual shifter to drive a car with automatic transmission.

    Future has automatic transmission. No need for SQL, for most things, if you don't want it. But just like you can find endless examples of tasks in 8 that require SQL (8 has nice SQL, not as nice as Future, but still very cool...), just so for Future.

    There is a huge amount of work you can do in Future without knowing a drop of SQL, just by using things like the Select and Transform panels. As more and more templates are added there will be even more capabilities that don't require any SQL. So positioning the matter as 8 being SQL-free while Future requires SQL is totally wrong and misleading. If you think that way you are denying yourself the use of a hugely powerful tool that in most (not all, but most) respects is much easier to use than 8. A good example of that is previews. You don't get any previews in 8 but you do with Future, which really helps avoid making mistakes and also helps zeroing in on doing exactly what you want to do.

    But beyond all that if you want to learn SQL to lift your game to much higher capabilities, to do work more effectively and faster and with less effort, well sure, it is truly great and wonderful to spend the utterly trivial amount of time required to get going with SQL. That's true for 8, and it is also true for Future. That Future has far stronger SQL than 8 is a good thing, not a bad thing, because it enables you to do far stronger things with SQL in Future than you could do with SQL in 8. All that is very good, and is not remotely any sort of a flaw. It is genuine progress.

    I have never met anyone who has sat down with, say, one of Chris Fehily's books and then spent a solid few hours learning SQL from the beginning who did not say, "wow... this is really all very easy. I don't know what the fuss was about..." Anybody smart enough to be doing GIS at all, at any level, is more than smart enough to realize from such an experience that starting with simple use of SQL is just a beginning, and right away will see that you can add to it to make it as complex and elaborate as you like. Or not.

    But I have met zillions of guys who never sat down to learn SQL from easy, simple basics who complain how hard it is on the basis of thrashing around poking at buttons and trying to figure out what is going on from master class examples like those Adam or Tim contribute to this forum. For lack of investing a couple of hours up front to start learning the thing properly from the beginning they'll spend a lifetime encountering frustration and complaining.

    Now, it could be that you are the one guy, the one exception in hundreds, who has sat down for some quality time with a Fehily book, and yet despite spending a few hours or a day or whatever learning the very basics, still thinks

    SELECT name, address, city FROM clients WHERE city = 'London' 

    is so totally complex it could not be understood by ordinary mortals. But I'd bet not. You don't need SQL at all to use Future and to do wonderful things.

    But if you make the trivial effort to learn the world's most widely used means of interacting with data you can do even more. And not just with Future but with a few thousand other packages. Nothing wrong with that!

    In 8 it needed no separate query. I could relate tables as fast as I could click and get all the fields from each one. With 9 each table needs a custom query which is not intuitively obvious to a SQL plebe like me.

    You could relate tables as fast as you could click in 8 because you had taken the time to learn how to do that. Beginners cannot relate tables as fast as they can be clicked in 8. It turns out you can relate tables even faster in 9 with even fewer clicks, (double-clicks, actually) to add tables using the query builder. It's not obvious to you because you've not yet learned how to do it. Once you do, you'll see it is even easier than in 8 while being far more flexible, far more powerful and much easier to maintain or to alter to adapt to changing interests.

    Those toolbars are always on at the bottom of the window, so I don't have to think about the process for finding the Transform pane.

    "Process for finding?" ... over the top given the zero effort of clicking Transform in an always-present, always responsive Contents pane. That's like complaining about the "process for finding" the kitchen in your own home. :-)

    Secondly they automatically switch modes depending on whether a table or map is in focus.

    Same with the Select and Transform panes.

    Third, most of the references in the Transform menu are understandable. In 9 it is often very cryptic (e.g. Parse GeoJSON, bounds, branch, Compose Point, copy (but no paste), etc.)).

    There's no "Paste" in the transform toolbar in 8. Many of the transforms have the same names. Some don't because they are different. For example, 8 has no ability to parse GeoJSON. If you work with GeoJSON you know what that means and you are happy to have that capability.

    I think 8 has reasonable names for templates but I respectfully disagree that names such as "Span Excluding" or "Decompose to Convex Parts" are automatically self-documenting for people who don't RTFM. You have to read the fine manual to understand what they do, and then beyond that you need some experience and familiarity with them before they start sounding obvious. Same with new Radian templates.

    Some of those, by the way, have different names from 8 analogs because Radian tends to be more precise than 8. A word like "bounds" is slightly more precise than "boundaries," for example, in that "boundaries" tends to imply internal dimension that only areas have while "bounds" tends to cover "extremities" or "markers" in a way that slightly (just slightly) is a better fit to the end points of lines or the single coordinate location of points. It's not like after a moment you wouldn't immediately recognize Bounds in the list of templates for what you used Boundaries in 8.

    It would be better to address the very long list of possible templates and how they can be handled. Future has yet to add all the various token operators, for example, and one reason is that you end up with very long lists (even longer than the long lists in 8) of templates that can be cumbersome.

    I can't imagine how many lines of SQL (that I don't have to learn) are buried in the 8 toolbars, and I appreciate it.

    Same with Future. You have hundreds of templates with not a single line of SQL you need to learn to use them. But, unlike 8, if you want to take your game to the next level Future will show you the SQL behind each template so you can modify it to suit variations or to learn.

    What is the motivation to change every aspect of a program that is just the next version?

    If Future were just the next version of 8, I'd agree with you. Future isn't the next version of 8. It is a completely new and different product. It does far more than 8 with endless detail in greater accuracy, rigor, sophistication, flexibility, capacity and more. Pretty much any new technology is like that: your smartphone has basically every aspect different from a rotary dial landline telephone. Zipping around on a jet ski is very different than paddling a canoe. Flying a jet with a glass panel requires significantly different cockpit design than flying a biplane.

    Sometimes when technology changes vendors will try to package new things in old wrappers to ease the transition. The very first automobiles, for example, were modeled on horse carriages. Until it became clear that to really take advantage of the new technology and to provide an even higher level of comfort, ease of use, and convenience it was better to design automobiles to be automobiles and not powered horse carriages.

    My challenge to you is to learn the new environment so you can take advantage of the power and convenience it delivers. Then, if you find something lacking or inefficient, say what it is so it can be improved. But stuff like this...

    but I don't like the inability to use mouse and kbd combinations to deselect

    ... is not helpful because it is so untrue you may as well be talking about Excel and not Future.

    Deselect? Trivial: If you like keyboard stuff, use Shift-Ctrl-A (a quasi-standard Windows thing) or Ctrl-A Ctrl-I. Deselect with a mouse? That's what the Shift modifier is for. See the video.

    Any place where Future is not more effective than 8 is fair game for complaint and improvement. But let's keep such observations to real things and not complain about things which are not at all about Future.

    Keep in mind as well that by using Future you are participating in an open beta program, so you should cut the documentation a bit of slack for being behind a very rapidly moving thing. The RTFM effort is harder with betas because you have to cruise on the basis of release notes and introductory videos as well as more finely worked documentation typical of a finished Manifold product. But that's part of the deal for getting access to the hottest technology right away and being able to influence where it goes.

    Last but not least, to make useful comparisons such as "A is a much better approach than B" you really have to know both A and B. If somebody recommends A because that's what they know and to learn anything about B requires some effort, well, as far as that goes it is a fair comment but it is not the same as being able to say that A as a way of working is better than B as a way of working.

    The comments you make about relations in 8 being so much easier than SQL seem to me to be an example of that. What you are really saying is that what you know how to do in 8 is much easier than something which you have not learned. Well, OK, I'll agree with that as far as it goes, but it doesn't go any farther than announcing that something which has not been learned cannot help you. It doesn't touch the idea that once you learn a bit of SQL you can do what you want to do with far greater ease, more power and greater flexibility than using relations in 8.

    And that's really the idea for which Manifold is created, to provide greater ease, more power and greater flexibility, all for less cost. You do have to learn to use it, but hey, that's to be expected for any worthwhile new thing, whether it is carpentry, learning to drive a car or even learning to ride a bicycle.

    dchall8
    341 post(s)
    #08-Nov-17 14:57

    Thank you for all that. In addition to being frustrated about the things Future doesn't yet do, I am frustrated that I cannot remember the simple stuff (Shift-Ctrl-Click). Perhaps for now I should stick to the things that Future can do (LiDAR) that Manifold 8 cannot and just enjoy the fortnightly-ish updates and videos as I can. As Future improves and I explore it more, maybe I can make it work for the daily grind before the final 9 release.

    Rather than importing a Manifold 8 project, I'm going to start with only the parcel drawing and build tools from there. That's how I started with Manifold 4, so I'll try that. Plus I need folders inside folders to be more organized, and importing a project scatters my 8 folder contents.

    Thank you again for your patience with me. I'll try to be patient with the Future open beta.

    Dimitri


    4,332 post(s)
    #08-Nov-17 15:42

    I'm going to start with only the parcel drawing and build tools from there.

    Sounds like a plan! Report progress here and ask any questions so we can pitch in to help.

    KlausDE
    6,054 post(s)
    #08-Nov-17 18:28

    I also thought about a sheet with all shortcuts. For instance I have forgotten the shortcut to open edit tools for curved segments and the key on a german keybord is not what help tells it should be. Guess I should have this laminated always at hand.

    pslinder1119 post(s)
    #09-Nov-17 00:31

    In 9 is Manifold planning to have buttons or some sort of GUI for each of the shortcuts? Or will some of the shortcuts be the only practical way of performing those functions?

    Dimitri


    4,332 post(s)
    #09-Nov-17 09:45

    the key on a german keybord is not what help tells it should be.

    The New Object Dialog is no longer enabled in Future editions, so Ctrl-/ won't work. Adding curved segments is something being migrated to the Coordinates tab of the Record panel so for now no entering of curved segments without rolling back to a prior build (trivial to do with portable installations...). ... all part of the fun of beta builds. :-)

    In 9 is Manifold planning to have buttons or some sort of GUI for each of the shortcuts?

    Can't resist... Yes. ...and...

    Or will some of the shortcuts be the only practical way of performing those functions?

    Yes.

    Given the very many Windows shortcuts as well as the Future-specific shortcuts, which are of interest to you?

    Some make sense to put in the GUI (File - Open or Ctrl-O) while others don't. After all the whole point of a keyboard modifier, say, to a mouse move is to not interrupt the flow of mousework with a click on some button or menu. It would be good to learn how you think that should be arranged.

    Remember, participating in an open beta is tall about saying what you think should be done. It's not to ask what will be coming, since that you find out by participating and seeing when it arrives.

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