Subscribe to this thread
Home - General / All posts - M9. Idea, meta data or freeform text notes for a table or drawing?
tonyw
736 post(s)
#21-Jan-19 19:30

As I process data, I end up with many variations of the same table or drawing which I try to distinguish with descriptive component names but I need more space than what I can practically do with a component name before they become unwieldy long. What do people think of the idea of a feature request, that in Properties for the Table or Drawing there is the opportunity to have a free form text box for notes-to-self? So the notes would be for the component and not for any particular record.

KlausDE

6,410 post(s)
#21-Jan-19 20:21

Strongly supported.I like the report of processing but not in the name. Adding a running number to the name and one new line for the protocol of the next geom transform template in a description would be better. And it would allow to add the name of the second component used in a process:

<timestamp>: Clip [x] with [y] keep inner

<timestamp>: Buffer [x] distance y.y with tolerance z.z

And geom transforms using only one input component should allow to choose between "add component" and "update field" to automatically replace the input component more often.


Do you really want to ruin economy only to save the planet?

tonyw
736 post(s)
#21-Jan-19 20:47

And geom transforms using only one input component should allow to choose between "add component" and "update field" to automatically replace the input component more often.

Agreed. I understand why "Add component"' is sometimes the only option as the geometry changes, but the names of components keep growing too and after a while are indistinguishable, other than the latest version tends to have the longest name.

KlausDE

6,410 post(s)
#21-Jan-19 20:49

We should be able to edit this 'description' property.


Do you really want to ruin economy only to save the planet?

tjhb
10,094 post(s)
#21-Jan-19 20:55

I very rarely used either the Description property or the Notes pane in Manifold 8. I knew I should, but on the rare occasion when I experimented with doing the right thing, I promptly forgot that I had, and wondered where my workflow notes had gone.

I doubt I would use similar features in 9 either--I think I need something more "in my face".

For workflow notes I use detailed Comments, plus component naming that sounds like what tonyw does.

On the other hand, I would like an option for the SQL used to create, alter or update a component (table, drawing or image) to be added to component properties. The same text as is currently written to the system log, plus the text that is written, or would be written, to the Command log.

That would be very verbose, but unambiguous, and the truth, and forensically accurate.

KlausDE

6,410 post(s)
#21-Jan-19 21:10

A flexible component naming would require a variable used everywhere in the query that we can edit in heading lines of the template query and/or an editable control.


Do you really want to ruin economy only to save the planet?

tjhb
10,094 post(s)
#21-Jan-19 21:15

I don't think so. Reporting the truth at a given moment would be more valuable I think. [I may have misunderstood you I think.]


How about being able to attach a single comment to a component, just like the comments that can be attached to cells in Excel (or like post-it, obviously). They could be shown by a yellow tag on the component icon, and appear as a tooltip on mouseover. (Possibly stored as a 'Tooltip' property.) That I would definitely use.

[I would use this much more than a "forensic" option, which is after all mostly provided by standard logging already.]

Klaus will remember this beta discussion.

tjhb
10,094 post(s)
#22-Jan-19 00:59

What already remains (questionable English) of the facilities that were available at the time of that beta thread (March 2016) is this:

If we open the Properties sheet for a component, and manually add a property named Description, then that will be shown in a tooltip on mouseover in the Project pane.

The text can have multiple lines, all shown in the tooltip. To add multiple lines easily, first create a Description property, then reopen Properties, right-click the right-hand field, choose Edit.

[Added. After that, you may need to hover over the adjusted text in the Properties dialog, and possibly click, for the new tooltip to show in the Project pane. A glitch.]

I had forgotten about this, but despite interface changes it still works, and is very useful.

Room for improvement: I would like to be able to add a Description by purely GUI means (e.g. right click -> Description...), and for its presence to be shown by a yellow tag on the component icon. That would be enough in my view.

tonyw
736 post(s)
#22-Jan-19 16:23

manually add a property named Description, then that will be shown in a tooltip on mouseover in the Project pane.

This is a great tip and does what I need, thanks. The reveal on roll-over is really handy. Adding to this feature what about the idea that the contents of the description field would appear when rolling over tabs in a Map, along with the full component name?

tjhb
10,094 post(s)
#22-Jan-19 22:04

That seems a great addition. Will you submit a suggestion to Sales? I plan to submit a report regarding the glitch mentioned above.


As I mentioned, I had forgotten that this feature already (or still) existed, and it's not obvious now that the Contents pane has replaced the Info pane (and Contents > Component does not expose the Description property).

It's a bit of a hassle to add a Description property manually, if you plan to do it to many components. Not much of a hassle--it's just that typing "Description" every time quickly stops being fun.

So to make things slightly easier, here is a short script to add a Description property for every component in the project (the root database, not any child databases), except for components which already have a Description set.

The initial description is the name of the component. Partly because a property can't be set blank; partly so that you can still see the name of a long component (in the tooltip).

From there it is easy to Edit the property to show a more detailed tooltip where that's useful.

// C#

// add default Description property

// for all components in root database

// where not already set

class Script

{

static Manifold.Context Manifold;

static void Main()

    {

        Manifold.Application app = Manifold.Application;

        Manifold.PropertySet props = app.CreatePropertySet();

        using (Manifold.Database db = app.GetDatabaseRoot())

        {

            using (Manifold.Table table = db.Search("mfd_root"))

            {

                using (Manifold.Sequence sequence = table.SearchAll(new string[] { "Name" }))

                {

                    while (sequence.Fetch())

                    {

                        string name = sequence.GetValues()[0].Data.ToString();

                        string desc = db.GetProperty(name, "Description");

                        if (desc == ""// no current property

                        {

                            props.SetProperty("Description", name);

                            db.SetProperties(name, props);

                        }

                    }

                }

            }

        }

    }

}

The attached version of the script has some extra comments removed above.

I plan to use this script as an add-in.

Attachments:
Set default description.cs

tonyw
736 post(s)
#22-Jan-19 22:08

Will you submit a suggestion to Sales?

Affirmative, I'll send a feature suggestion to Sales.

tonyw
736 post(s)
#22-Jan-19 23:11

Suggestion to Sales sent

tjhb
10,094 post(s)
#22-Jan-19 23:54

Cool.

As to the glitch with editing (and the edit not showing in the tooltip), I can't isolate it well enough to send in a report.

I've also seen cases where a tooltip persisted even after the property was deleted, but can't reproduce this at will.

I get the impression that it is much better in 9.0.168.7 than in 9.0.168.0. I'll keep watching.

By the way, thanks for asking this question, and prompting me to remember (dimly) that it already exists. I'm glad it does.

tjhb
10,094 post(s)
#23-Jan-19 01:40

Sorry, the .cs script "attached" above is not. Try again as .txt.

And it doesn't add a Description property for folders. That has a slightly different mechanism. Folders are not listed in mfd_root, but defined by "Path..." properties in mfd_meta. Easy enough to add this.

Attachments:
Set default description.txt

tonyw
736 post(s)
#23-Jan-19 16:50

This is great, thanks for creating the script

tjhb
10,094 post(s)
#23-Jan-19 22:58

Here is a revised version. Changes:

  • adds a default description for project folders, as well as for components
  • does not add a description for mfd_root or mfd_meta

  • writes a log entry for the descriptions added and shows the log.

    // C#

    // add default Description property

    // for all components and folders in root database

    // where not already set

    class Script

    {

        static Manifold.Context Manifold;

        static void Main()

        {

            Manifold.Application app = Manifold.Application;

            Manifold.PropertySet props = app.CreatePropertySet(); // reused

            using (Manifold.Database db = app.GetDatabaseRoot())

            {

                // process root components

                using (Manifold.Table table = db.Search("mfd_root"))

                {

                    //using (Manifold.Sequence sequence = table.SearchAll(new string[] { "Name", "Type" }))

                    using (Manifold.Sequence sequence = table.SearchAll(new string[] { "Name" }))

                    {

                        while (sequence.Fetch())

                        {

                            string name = sequence.GetValues()[0].Data.ToString();

                            //string type = sequence.GetValues()[1].Data.ToString();

                            if (name == "mfd_root" || name == "mfd_meta")

                                {

                                // pass

                                // (can set properties, but little point)

                                }

                            else

                            {

                                string desc = db.GetProperty(name, "Description");

                                //app.Log(string.Format("[{0}] : '{1}'", name, desc));

                                if (desc == ""

                                {

                                    // no current property

                                    // add property, using component name as default description

                                    // (can't be blank)

                                    props.Clear();

                                    props.SetProperty("Description", name);

                                    db.SetProperties(name, props);

                                    app.Log(string.Format("[{0}] : '{1}'", name, db.GetProperty(name, "Description")));

                                }

                            }

                        }

                    }

                }

                // process root folders

                using (Manifold.Table table = db.Search("mfd_meta"))

                {

                    using (Manifold.Sequence sequence = table.SearchAll(new string[] { "Name""Property""Value" }))

                    {

                        while (sequence.Fetch())

                        {

                            string name = sequence.GetValues()[0].Data.ToString();

                            string prop = sequence.GetValues()[1].Data.ToString();

                            string value = sequence.GetValues()[2].Data.ToString();

                            //app.Log(string.Format("[{0}] : '{1}' '{2}'", name, prop, value));

                            if (name == "mfd_root" && prop.ToLower().StartsWith("path"))

                            {

                                string[] tokens = prop.Split('.');

                                if (tokens.Length == 3 && tokens[0].ToLower() == "path" && tokens[2].ToLower() == "value")

                                {

                                    // property defining a folder

                                    // find record (if any)

                                    // with Property in form "Path.<id>.Description"

                                    // for matching path id

                                    string id = tokens[1];

                                    string match = "Path." + id + ".Description";

                                    Manifold.ValueSet values = app.CreateValueSet();

                                    values.AddValue("Name""mfd_root");

                                    values.AddValue("Property", match);

                                    Manifold.Sequence record = table.Search("Name_Property_x", values, new string[] { "Name""Property" });

                                    if (!record.Fetch())

                                    {

                                        // no matching record

                                        // add record, using path (value) as default description

                                        props.Clear();

                                        props.SetProperty(match, value);

                                        db.SetProperties("mfd_root", props);

                                        app.Log(string.Format("[{0}] : '{1}'", match, db.GetProperty(name, match)));

                                    }

                                    record.Dispose();

                                }

                            }

                        }

                    }

                }

            }

        app.OpenLog();

        }

    }

    Attachments:
    Set default description.txt

  • tjhb
    10,094 post(s)
    #24-Jan-19 00:59

    Revised (cleaner).

    Attachments:
    Set default description.txt

    KlausDE

    6,410 post(s)
    #22-Jan-19 12:00

    [I may have misunderstood you I think.]

    I was unclear and I was wrong. I'm still used to think in terms of drawings and not tables.

    So in Options of transform templates creating new components I changed only the name for the resulting drawing and found myself in a messed up project pane with no similar names of drawing and underlying table.

    Thinking in the new table centering way I have to change the result table name in Options dialog and find the appropriate drawing name set by default.

    I'm curious how long it will take to really incorporate the 'Everything is a table' approach


    Do you really want to ruin economy only to save the planet?

    adamw


    10,447 post(s)
    #01-Feb-19 14:44

    A couple of things based on the contents of the thread:

    1. We have been planning to re-add controls to show / edit component description in Contents - Component. We used to have a second property doing almost the same thing as Description - Notes - that won't be re-added, instead we'll extend what we do with Description slightly.

    2. Which transforms that don't have Update Field should have it? Typically, transforms that don't have Update Field don't have it because they add or remove records - if we were to allow Update Fields, that would be losing values in fields not used by the transform. That might be acceptable sometimes, but we are naturally vary of exposing potentially destructive options in the UI and making them so easy to reach...

    3. For Add Component, we were thinking about maybe putting a text box with the name of the new component right into the pane. That would cost some screen space though. Maybe the area with the parameter controls should be scrollable. We'll see.

    Also, we would love to be adding to the component description automatically. However it might be a better idea to instead be saving the log into the top-level MAP file - this would capture everything in a single place.

    tonyw
    736 post(s)
    #01-Feb-19 18:29

    Thanks Adam.

    Regarding #2. I frequently use Transform > Overlay Topology Identity and an Update Field option would be handy rather than generating a new component each time. An example of Overlay Topology Identity and ensuing components is given an area of interest (let's say it's wildlife habitat), the question is how much of that habitat lies in provincial park, on private property, or is river bed? So that could be three Transform Identity transformations yielding three new components with ever expanding component names. So component names soon become unwieldy.

    However if it is still more straightforward to add new components then could the strategy be that the new component acquires the name of the original target component? So if I have a component named "wildlife habitat" and I performed a Transform > Overlay Topology Identity transformation, then the new component retains the name "wildlife habitat" and the original target is renamed "wildlife habitat 2 Overlayed Topology" (note "overlayed" in past tense plus addition of the number for multiple occurences of the same component name).

    For instance, when I copy and paste a component, the new component retains the same name with a sequential number added. The same scheme could work with Transformations. So incremented number + name of the last transformation. Then if I need to do re-work, I know the sequence of transformations and if I make a mistake after creating "wildlife habitat 14 Transform > Decompose to Branches" I can go back to "wildlife habitat 13 ..." or maybe even "wildlife habitat 12 ..." and start again. Still the product of the transformation is component retaining the original component name "wildlife habitat".

    Regarding #3. Yes, having a free text box and being able to add notes or comments while adding a component would be really handy. At the point of deciding on a name for the component I'm also thinking of how that component serves my process. Adding comments at that time would be useful.

    On the idea of a top level log, if that's to replace free form text on components, I would still prefer comments attached to each component. If the top level log is for the . map file, that would be really useful too. I keep separate notes "Created at Jan 29, 2019 meeting with client. Addressed roads within 25 m of water bodies. Tested relocating roads through X and Y. Sent draft map to client Jan 31, 2019. Etc."

    Thanks for considering.

    adamw


    10,447 post(s)
    #02-Feb-19 08:53

    Regarding Update Field - thanks for the example. Overlay Topology, Identity is a relatively tame case here, because objects are treated individually, but nevertheless, we see why you'd like to have Update Field for it. Same for Union / currently not existing but coming Split referenced by Klaus.

    Maybe we can try to address this universally for all transforms. There are several big issues to work out. Eg, we have to provide some recovery if the transform fails mid-way - this is much more difficult with an update that adds or removes records from an existing table. But maybe these issues are solvable.

    Regarding naming new components after original ones - that's already how it is done. If there is a drawing 'Roads Drawing' on a table 'Roads' and you overlay it with a drawing 'States Drawing' on a table 'States', the result table will be named 'Roads Overlay Topology, Identity' and the drawing the same with 'Drawing' added. You can change the default names before performing the transform by clicking the Options button in the pane, too. The problem with automatic names is that - as has been noted - they quickly become too long to be useful.

    KlausDE

    6,410 post(s)
    #01-Feb-19 22:26

    Regarding #2: One of the most used transforms for me are A "split with" B and "union". And though I know they create new objects I almost always want them to replace objects in the original component keeping attributes with transfer rules. Actually I still use an ODBC link from Mfd8 for editing while digitizing is done in Mfd9 with its superior support of wms servers. Changing the application up to now is easier than handling a mass of intermediate components and objects regardless of of the present naming of components.

    Unlike Tony I don't want source components to become renamed. This may break existing queries and workflows. But the Mfd8 way of naming the results of transforms is OK for me. It could be enhanced by always adding the next highest running number not filling up gaps in the series. It's easier to recap the steps of development then.

    Regarding #1 and a verbose Log: I endorse a top-level Log but it should be possible to copy selections of the log an paste them in some description.


    Do you really want to ruin economy only to save the planet?

    tonyw
    736 post(s)
    #02-Feb-19 00:03

    Unlike Tony I don't want source components to become renamed. This may break existing queries and workflows. But the Mfd8 way of naming the results of transforms is OK for me. It could be enhanced by always adding the next highest running number not filling up gaps in the series. It's easier to recap the steps of development then.

    Agree with Klaus, I forgot about that consequence of renaming source components and breaking the link to dependent components such as Drawings. So renaming the resulting component was my way to end up replacing objects in the original component (by multiple steps: create the new component, rename the original component to something else, then rename the new component to the name of the original component).

    adamw


    10,447 post(s)
    #02-Feb-19 08:58

    Regarding saving the log into the MAP file - this could be a system-maintained comments component, or, maybe better, a system-maintained table. Eg, near mfd_root / mfd_meta we'd also have mfd_log = a table with a running log of records with fields for: mfd_id (sequential index), date (date and time of the operation), description (text), maybe also a field for user name or GUID to keep track of which machine / install performed the action, maybe also a field for operation type (transform / script / import / whatever). Or maybe less is more and just plain text which you could easily copy / paste into anything would work better.

    tjhb
    10,094 post(s)
    #02-Feb-19 22:11

    Regarding saving the log into the MAP file ... Or maybe less is more and just plain text which you could easily copy / paste into anything would work better.

    I like this thinking, would liike to add a related consideration.

    Currently we have the main Log window (View > Panes > Log window, or Ctrl-L), and that is written almost verbatim to disk, by default to C:\Users\<user name>\AppData\Local\Manifold\v9.0.

    Each Query window and Command window also has its own Log tab, for immediate output, verbose if !fullfetch is on.

    If a further log format is added in future, it could be an opportunity to review and rationalize all logs at the same time.

    For example, the Query and Command Log tabs might in principle be removed, and their output redirected to the main Log window, with an indication of the source. I'm not sure if I would like this (and I don't know if it would work). An alternative might be to keep the Log tabs, but to duplicate their output to the main Log window, possibly as a user option.

    Similarly, I would like a new option for SQL created implicitly by the Transform operations (that is, the text that would be shown in a Command window if the Edit Query button is pressed) to be written to the main Log window, again with an indication of source. (Except perhaps where the SQL would not be an exact match, as is currently true for Selection transforms, though that might change in future--I hope so).

    If a new log facility is added, saved into the current map file, I think it would be simplest if this exactly matched the text written to the Log window during the current session. (The new text could be appended to the embedded log if the project were saved with File > Save, or written clean for File > Save As.) I suggest that both the new embedded log, and the log saved automatically to disk, be made optional. (Or perhaps better: to require at least one, but allow both.)

    The gist is I think that there should not be too many different kinds of log, because that would be confusing. It is better, I think, for there to be basically just one kind of log, with options about where and how it is saved, and possibly about how much detail is included in it.

    tjhb
    10,094 post(s)
    #02-Feb-19 22:34

    ...and the ability to add user comments in line, yes.

    That could also solve the question whether to keep the Query and Command log tabs, or integrate them into the main Log window. In short: keep them as they are, but add a right-click option to copy selected text from the log tab to the main Log (though manual copy and paste would also be fine).

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