Attach Custom Record...to everything

[ericjhberg]

This may be considered a wishlist, but honestly I have no idea if this functionality may already exist somehow in Vectorworks...here we go.

 

Is it possible to set up a default that would automatically attach a custom record format to everything placed in a drawing, retroactively and to all future drawn objects?

 

The reason. We have started to use custom record formats to gain some additional functionality out of certain tools or features, but we can run into difficulty in an office setting where multiple users are asked to know what record to attach to what and to make sure to attach it to any new objects placed.

 

I would love the ability to create a very generic custom record format that covers many of our additional functionalities and ensure that it will be attached to everything in the drawing. I can worry about using other criteria to limit my selections later (usually type, class, layer, etc.).

 

Just curious?

 

[michaelk]

Famous last words:  That should be easy to script .

 

What do you do about container objects?  (Groups, symbols).  Do the objects in side the group or symbol also have the generic record attached?

[Urbanist]

10 minutes ago, michaelk said:

Famous last words:  That should be easy to script .

 

Maybe, if one does not consider the requirement "what record to attach to what":

 

Anyway, I don't think that the available scripting languages can monitor the document and act when a new object is created. Maybe a C++ program done with the SDK could, but I would not call that scripting. 

 

A script that would retroactively process all objects is technically simple to do, but the "what to what" clause is likely to complicate things quite a lot.

 

 

[michaelk]

You're right about that.

 

Here's  one that does it retroactively.  It does attach the record to objects in groups, but not objects in symbols.

 

PROCEDURE UniversalRecord;

VAR
	
	UniversalRecordName: STRING;

	
	


	PROCEDURE AttachIt(h : HANDLE);
Begin

	SetRecord(h,UniversalRecordName);

End;

{Main Program}	

Begin

UniversalRecordName := 'Test Format';

ForEachObject(AttachIt,((NOT (R IN [UniversalRecordName]))));

End;


RUN(UniversalRecord);

 

[Urbanist]

Databasewise a universal record is desirable so that the collected data can be efficiently processed in a separate database application with a reasonably simple schema. (Database in my world always refers to a real, relational database, not Excel.) 

 

The what to what -thing is not necessarily simple. I once tried to create a universal QS database and as far as the entity type was a sufficient way to determine th whats, I only needed to check whether the object being is processed is a bird or a plane. Certain other implicit items of data (file, layer, class, symbol name) were easy, but after wasting heaps of time (and not being a quantity surveyor) I gave up. 

[Pat Stanford]

2 hours ago, ericjhberg said:

I would love the ability to create a very generic custom record format that covers many of our additional functionalities and ensure that it will be attached to everything in the drawing. I can worry about using other criteria to limit my selections later (usually type, class, layer, etc.).

 

 

In my NSHO, this is not something you want to do first and as far as I know, this is not possible in VW using any means.

 

A huge enough record format to cover every possibility is going to be almost impossible to use properly and keep the data in properly. It will also make everything else in the drawing slow down.  Currently something like a line has to keep track of about 20 pieces of data (XYZ of begin and end, Type of object, Attributes. If you add a record with 100 fields, then VW needs to work with that much more data. For every single object in the drawing.

 

What might be reasonable, would be to make prototypes of your most important object and then make symbols out of them to make them into resources. Have the Convert to Group/Object insertion option set. Then you just have to train your users to ONLY insert object from the resource manager and never use any of the VW tools or menu commands to draw anything.

 

I think this is one of those pipe dreams that sound like they would be very useful, but that the upkeep on them will kill any benefit very quickly.

 

Sorry to be a buzz kill.

[Urbanist]

14 minutes ago, Urbanist said:

The what to what -thing is not necessarily simple. I once tried to create a universal QS database and as far as the entity type was a sufficient way to determine th whats, I only needed to check whether the object being is processed is a bird or a plane. Certain other implicit items of data (file, layer, class, symbol name) were easy, but after wasting heaps of time (and not being a quantity surveyor) I gave up. 

Just a few minutes later, in sudden moment of clarity, I remembered why I gave up. I went through a few decades of projects and realised that to get what I wanted would have required a huge number of wall types that would incorporate the painting system on each side and the facility to query those. My architectural English is even more lacking than my basic English, so forgive me for the long explanation. With painting system I refer to the entire surface treatment from structural wall to finish. Eg. in painted brick or blockwork walls there can be quite a lot of variation within a project. Eg. in a hospital or similar the corridor sides have simpler surfacing than in operating room sides. Once upon I time I embarrassed myself seriously by having an inadequate base for a hospital-grade painting. The client, fortunately, was forgiving although strictly speaking I could have been required to pay for the variation.

 

To quantify all this to a useful level for cost estimates just got too complicated, not to even mention the requirements to the VW user. 

[Art V]

12 hours ago, ericjhberg said:

This may be considered a wishlist, but honestly I have no idea if this functionality may already exist somehow in Vectorworks...here we go.

 

Is it possible to set up a default that would automatically attach a custom record format to everything placed in a drawing, retroactively and to all future drawn objects?

This would definitely be useful in some situations, though I'd like add something to the idea.

 

E.g. when exchanging updated files with GIS software. Clients sometimes have default records attached for standard information to be recorded. If I am adding new things to the imported GIS data and then send it back the new items should preferably have these records attached and where necessary filled out.

So for such a situation the option to automatically add a specified record to new objects would be quite useful as I would not have to do that afterwards through the OIP object. It would even be better if there would also be a fill-out dialog box as you can have with symbols upon inserting as an additional option to be set on/off.

 

So I'd like to expand a bit on your wish:

1. have the option to attach a record of choice (from any record available in the resource browser) for future objects when they are drawn, optional to attach that record to existing objects as well. And also be able change this at any time during the session for another default record attach for new objects.

2. have an  option that when a new object is created to which the abovementioned record gets attached there will be a dialog for filling out the records where necessary. That would avoid missing objects to add info to in such a situation. This is already possible with symbols, but it might be an option for records too without having to go to the OIP, select data tab etc. (Though VW2018's setup might be convenient enough, but don't have it yet).

[Urbanist]

39 minutes ago, Art V said:

 

So for such a situation the option to automatically add a specified record to new objects would be quite useful as I would not have to do that afterwards through the OIP object. It would even be better if there would also be a fill-out dialog box as you can have with symbols upon inserting as an additional option to be set on/off.

A valid point indeed! A script that would attach records to objects without it and meeting some criterion (eg. layer) should be very easy to write. 

 

Possible concept. 1. User selects an object with the record attached. 2. The menu command (script) creates a list of objects on the layer of the selected object, but without the record attached. 3. The record is attached to each object on the list, possibly with a date stamp. 

 

Maybe 30 lines of VectorScript. Roughly 1 or 2 hours of work by a novice scripter. 

 

A simple dialog for entering a single shared piece of data (eg creator) to all processed objects, typed by the user. Additional 3 or 4 lines of code in 5 minutes. 

 

A fancy "modern" dialog for entering possibly required other data, with predefined drop-downs, but still without flashing lights and small fanfares at least until VW 2019. Maybe 300 lines of VectorScript. Roughly 20 hours of work by an expert scripter. Drop-downs that learn like those in FileMaker Pro: not the slightest idea even of the doability and elegant to use they would not likely be. (A short technical explanation may be needed: in FMP, a drop-down value list can be defined so that in addition to items given by the programmer, a user can type another value and that then is available in all records. it is not magic, it is the index of the field in question. No such thing in VW.

 

Edited October 1, 2017 by Urbanist

[Hippocode]

I think this is a great idea. I'll see if I can come up with something using the SDK.

[ericjhberg]

Wow...I'm glad that this question has brought out the big guns!

 

A couple of thoughts from the novice.

1. Agreed that a large record attached to everything would likely be cumbersome...but what about a small record (15 fields max)?

2. 23 hours ago, Urbanist said:

   Possible concept. 1. User selects an object with the record attached. 2. The menu command (script) creates a list of objects on the layer of the selected object, but without the record attached. 3. The record is attached to each object on the list, possibly with a date stamp. 

   I love this idea. Some way to easily see what items have the record attached vs. those that don't and then a quick way to attach the record to those remaining that need it.

3. What about a future wishlist...like the 'Use at Creation' check under Edit Class(es), that, in addition to the Graphic Attributes, Renderworks, Text Styles, etc.,  there be a Data Tab that would allow you to select a record format to apply to all items within a class (both retroactively and at creation).

I'm excited to see where this goes...

[Hippocode]

I managed to get a simple example working, being able to map a specific record to any object type. These records would be attached on object generation so you would never need to worry about the correct additional records being attached as all is handled in the background. In theory is any object valid, including custom objects for those of you that script a bit.

 

You could even take it a step further and allow to use different records on the same object type, based on parameter values. Lets say you have some sort of "type" value associated to the parametric record, we could set it up that you could define different secondary records to become attached on those occasions for your specific needs.

 

To handle at least a basic mapping, this needs some additional time spent on, as we need a decent dialog to manage and store all of this in the drawing.

I'm convinced this can be very beneficial to any workflow and have decided to add it to our 2018 release of VectorMEP. 

 

I don't think your drawing would become heavy if you would add larger records to multiple object types, but then again such above interface would allow you to organize it a bit better and make specific records for each situation anyway.

 

[Art V]

2 hours ago, ericjhberg said:

1. What about a future wishlist...like the 'Use at Creation' check under Edit Class(es), that, in addition to the Graphic Attributes, Renderworks, Text Styles, etc.,  there be a Data Tab that would allow you to select a record format to apply to all items within a class (both retroactively and at creation).

Now, that would be really useful to have for something like this as it would add the flexibility of using two classes, one for the drawn objects and one for the text and have the record be attached to only the class containing the drawn objects and not to the text objects.
At least for GIS related stuff this would make a difference as text objects generally do not get records attached.

If this could be combined with Wouter's (Hippocode) plugin then it would be a best of both worlds for those using the plugin.

[Art V]

24 minutes ago, Hippocode said:

I managed to get a simple example working, being able to map a specific record to any object type. These records would be attached on object generation so you would never need to worry about the correct additional records being attached as all is handled in the background. In theory is any object valid, including custom objects for those of you that script a bit.

 

You could even take it a step further and allow to use different records on the same object type, based on parameter values. Lets say you have some sort of "type" value associated to the parametric record, we could set it up that you could define different secondary records to become attached on those occasions for your specific needs.

 

To handle at least a basic mapping, this needs some additional time spent on, as we need a decent dialog to manage and store all of this in the drawing.

I'm convinced this can be very beneficial to any workflow and have decided to add it to our 2018 release of VectorMEP. 

 

I don't think your drawing would become heavy if you would add larger records to multiple object types, but then again such above interface would allow you to organize it a bit better and make specific records for each situation anyway.

 

That's fast

 

A question, will this plugin be part of the Basic (Extension Bundle version) or the Premium (Extension+MEP) version?

Something to consider, though I doubt it will have much impact overall given your description, for GIS Shapefiles can have only one record attached, but upon export to shapefile one can select the record to be used during export. The one thing to be very careful of in a GIS related situation is that attaching records should never replace modify/merge with existing records unless explicitly executed/approved. Usually the same record as for the existing object will be added, though its values may be different for some or all fields. It might be something to keep in mind when creating options for attaching records to avoid users selecting an option that would cause accidental changing/replacing of existing records (at least not without a warning) as I am not sure yet how your type value for parametric records would affect existing records. (I'm not a scripting person)

[Hippocode]

2 minutes ago, Art V said:

That's fast

 

A question, will this plugin be part of the Basic (Extension Bundle version) or the Premium (Extension+MEP) version?

Something to consider, though I doubt it will have much impact overall given your description, for GIS Shapefiles can have only one record attached, but upon export to shapefile one can select the record to be used during export. The one thing to be very careful of in a GIS related situation is that attaching records should never replace modify/merge with existing records unless explicitly executed/approved. Usually the same record as for the existing object will be added, though its values may be different for some or all fields. It might be something to keep in mind when creating options for attaching records to avoid users selecting an option that would cause accidental changing/replacing of existing records (at least not without a warning) as I am not sure yet how your type value for parametric records would affect existing records. (I'm not a scripting person)

The plug-in will be available in both bundles.

 

Currently I verify if the record is attached, it will only be added if not yet present. Thus you should never get any collisions. Also these will be attached on object generation (before you will be able to do anything with the object).

 

I have no knowledge about that GIS object. Why can you only add one record ? Seems strange

[Art V]

39 minutes ago, Hippocode said:

The plug-in will be available in both bundles.

 

Currently I verify if the record is attached, it will only be added if not yet present. Thus you should never get any collisions. Also these will be attached on object generation (before you will be able to do anything with the object).

 

I have no knowledge about that GIS object. Why can you only add one record ? Seems strange

Thanks for the info.

Objects in VW can have multiple records even if they are meant for GIS purposes, but a shapefile only allows one record (with multiple fields) per object. It is not GIS limitation per se but more a limitation of shapefile and/or GIS program ( depending on the GIS program)
The advantage for GIS in VW is that you can use the client's record and also your own record. With most GIS software it requires the use of databases (e.g. postgis) to achieve the same.

[Urbanist]

8 hours ago, Hippocode said:

I have no knowledge about that GIS object. Why can you only add one record ? Seems strange

When you put up your hand, I knew you would crack it! '

 

In the GIS programs I know, only one record (ie. alphanumeric component of the geometric object) is possible. A GIS program typically stores the data in files, one for the geometry, another for alphanumeric data. The latter can be either of a proprietary type or generic, such as DBF. 

 

I once wrote a MapInfo export facility for a client's very specific use of VectorWorks. There was a published interchange format (MID/MIF)  in which the geometry description was not entirely unlike than that used by VectorScript, but it was quite a challenge anyway. Actually the graphic representation (only symbols in VW) was simplified to be extremely symbolic (a rectangle for each symbol) because the very large number of items and the intended thematic mapping of the items. The system had to be very easy to use (the client was not in design business and VW users had little skills) and absolutely reliable as the MapInfo part was an integral part of their business planning. Shamefully, in this project I profited from gambling: the rectangles were poker machines and the purpose of thematic mapping was to maximise their performance by analysing the impact of location in the premises. 

 

I also wrote an import script, but getting that to be generic in the alphanumeric side was too difficult. I then used ad hoc -variations of the script to import clients' MapInfo data, which was extremely useful in our urban design practice. 

[Art V]

Based on what I have read, but have yet to get into PostGIS, databases like PostGIS can have multiple records for a single object provided the object has a unique ID. The GIS software may only be able to use one record at a time unless you do a table join to merge multiple records, but it should be possible to change the record linked to the object without destroying data. Unless that information is incorrect.

Which is another reason why I like Vectorworks, the ability to attach multiple different records and then pick the one you want/need upon export to a Shapefile without having to mess with original records and information.

[Urbanist]

1 hour ago, Art V said:

Based on what I have read, but have yet to get into PostGIS, databases like PostGIS can have multiple records for a single object provided the object has a unique ID. The GIS software may only be able to use one record at a time unless you do a table join to merge multiple records, but it should be possible to change the record linked to the object without destroying data. Unless that information is incorrect.

Interesting, good to know. 

 

However, SQL is definitely not my forte (IMHO, SQL is set theory made difficult) and it seems that PostGIS works only with PostgreSQL; also I am somewhat suspicious as comes to free and open-source software. Free is often exactly worth the price. 

Edited October 3, 2017 by Urbanist
Added commentary re SQL

[Art V]

1 hour ago, Urbanist said:

IHowever, SQL is definitely not my forte (IMHO, SQL is set theory made difficult) and it seems that PostGIS works only with PostgreSQL; also I am somewhat suspicious as comes to free and open-source software. Free is often exactly worth the price. 

It has been a while since I used SQL but am getting back into it in the near future because of PostGIS/PostgreSQL.

 

There is a lot of free software that is lacking but there is also quite a bit of free software that works quite well, PostgreSQL and e.g LibreOffice are two of them that are well known, and QGIS is no slouch either though ArcGIS is more advanced it also costs a lot more and not everyone needs the advanced features.
I know of a top 50 Fortune 500 company using QGIS in addtion to ArcGIS (their main GIS software in addtion to other paid GIS software)  and they would not use it if it wasn't meeting a certain minimum quality level.

I don't mind using free software provided it is reputable/of good quality, as it is sometimes the only way to enable others to participate because they cannot afford the (sometimes very high) costs of the commercial software options.

[Urbanist]

12 hours ago, Art V said:

There is a lot of free software that is lacking but there is also quite a bit of free software that works quite well, PostgreSQL and e.g LibreOffice are two of them that are well known,

For unfortunate reasons that are irrelevant in this context I've used LibreOffice for roughly a year now and if that is good free software, I don't want to have anything to do with that of lesser quality. If I'd need to do some real work with LibreOffice, I'd start to hate computers even more than I do now. Simply shocking in every respect! 

 

Your point about allowing collaboration by people of lesser means is, however, most relevant. 

Edited October 4, 2017 by Urbanist
Typos fixed, clarification added

[Hippocode]

There is one tiny drawback, these settings are global (beyond the scope of a document) and you need to restart Vectorworks each time you modify the mapping settings.

The settings are kept in a XML file that can be shared.

As a precaution you can not attach hidden or parametric records for obvious reasons.

 

Edited October 4, 2017 by Hippocode
I tried to make the image smaller, I can't :(

[JMR]

A bit like what is discusse here....we use "select similar" to make sure all similar objects have the correct record attached. Also viewport data visualisation can be used to check this.