HOTSPOTs and Associative Dimensions

[James Murray]

I’d like to bring to your attention an issue with dimensioning objects that I would call a bug. Scripted HOTSPOTs in 3D (not bounding box, not A/B/ZZYZX) can’t be dimensioned to associatively. (Example: A wall light fixture might have a HOTSPOT at its mounting point so the above-floor distance can be dimensioned in elevation.) Strangely, the dim can be made associative by dragging the dimension node onto the point using the dimension editing pet palette. This is, to say the least, sub-optimal and hard to discover, and hard to train. It also gives me hope that it can be easily fixed.

In the meantime, my workaround is to create a hidden length parameter, LOCK it, and then script a set of editing hotspots for it. GEHs can reliably be assertively dimensioned. The only trouble is the node looks editable though it doesn’t do anything. Actually, the other trouble is, this is a bug and it should be fixed.

One more thing, I really appreciate the cursor behavior when using the dim node moving pet palette button – how you get feedback with a circle or square before you click the point. It would be great if the dim tool did this for initial placement.

James M

[James Murray]

Associatively, not assertively, dimensioned #stupidautocorrect

James M

[Barry Kelly]

Are you sure?
I dimension to standard hotspots (3d hotspots in sections and elevations) in my objects all the time.
Have never had any problems with them being associative.

However you do need to (or I think it is best to) have unique IDs (that don’t change – i.e. don’t use UNID = UNID+1 between hotspots) for each hotspot.
If you don’t have IDs you can still associate dimensions (I think) but they associate to the auto ID so dimensions can disappear or associate to another point if a hotspot isn’t used in a script (i.e. inside an IF / THEN routine) – thus changing the auto-ID numbering.
This is why it is best to hard code the ID for each hotpot.
This however becomes a problem when you CALL macros or use GOSUBS that also have hotspots as you need to increase their ID numbers to keep them unique.

Barry.

Versions 6.5 to 22
Dell XPS- i7-6700 @ 3.4Ghz, 16GB ram, GeForce GTX 960 (2GB), Windows 10
Dell Precision M6800 - i7 4700MQ @ 2.40GHz, 16GB RAM, AMD FirePro M6100 (2GB), Windows 7 64bit

[James Murray]

You are correct, HOTSPOTs with IDs work. I swear I checked that, smh.

I think hard coded IDs are too weird for me, I would have to think through the contingencies of that. For the cases I am thinking of, I don’t think the incremented ID could vary.

It still makes no sense to me as a user that I can impose associativity on a point that the dim tool can’t by itself.

Thank you Barry!

James M

[James Murray]

The more I think about this, it’s just wrong and we shouldn’t be concerned with it. What should happen is scripted hotspots should be associative even with no ID. And in fact, they already are, if you use the palette editing. Then I would not give that hotspot an ID, because it is in fact more reliable (no ID to change accidentally or increment wrong.)

We still have the problem of dimming to GEHs, which must have IDs. I can’t reconcile hard coded IDs with parametrics, I’ll need to try a real world case.

James M

[Author]

Posts