Jump to content
Developer Wiki and Function Reference Links ×

Tool macro doesn't snap to extension lines!


WhoCanDo

Recommended Posts

This simple macro, which makes it easier for me to draw parallel lines throughout the day, works as a macro in Vectorscript Palettes but does not work properly as a tool.

1. I want the StrDialog question before the tool activates. Why in Vectorscript Palettes does the StrDialog activate first but as a tool it activates after the first point is selected?

2. Hovering over an object vertex and then moving away shows extension lines. In the Vectorscript Palettes if the mouse moves slightly off the extension line and then pick a point, the picked point is actually along the extension line (ie. correct). Why doesn't a tool work in the same way? Picking a point slightly away from the extension line with the tool actually picks the point under the cursor.

How can I resolve these problems?

procedure Parallel_Line_Tool;

var

Line_Separation : real;

begin

Line_Separation := GetDLSeparation;

Line_Separation := Str2Num (StrDialog ('Spacing?',Num2StrF (Line_Separation)));

SetDLOptions (0);

SetDLSeparation (Line_Separation);

CallTool (-216);

end;

run (Parallel_Line_Tool);

Link to comment
By definition, a Tool requires a click, a Command does not.

After the click, all user interface methods should be available, though.

EDIT

Your script would work best as a Menu Command with a keyboard shortcut.

Then the script will not work the way the person wants it to work.

Hardly "Best."

More like, "Your script will be limited in a different way by the failures of the user interface."

The theoretical tool/command distinction should be independent of the interface used to access...the restriction of the icon interface to tools is inexcusable.

BTW, I've recently realized that part of the UI limitation is the fact that you cannot modify the contents of the workspace transparently. Just rearrange the deck chairs.

Link to comment

Then the script will not work the way the person wants it to work.

Hardly "Best."

More like, "Your script will be limited in a different way by the failures of the user interface."

Well, tough! Welcome to reality: things may not work the way you want.

Can you please ask Mother Brudgers to buy you AutoCAD to play with?

Link to comment

This again...

Here's the deal. If you want tool behaviors beyond the capabilities of v-script you just have to learn to use the SDK.

Vectorscript is not a full-fledged programming language. It has limitations, but the payoff is that you get a lot of behaviors with no programming whatsoever. And you don't have to work with that god-awful acad script either.

If you want different behaviors then start learning C++ or whatever they're using these days.

Nobody's defending anything. Just trying to explain how it is to somebody who might think they can do something they can't.

Kool's advice is spot-on and no amount of belly-aching will change that.

Well, not anytime soon at least.

Link to comment

Whatever logic is behind distinguishing between tools and commands does not encompass the fact that you cannot run a command from an icon (particularly since you can both run tools and commands from the other user interfaces (drop down menus and the keyboard).

Heck you can even click on the name of a script and it will run a command despite being in a pallet.

The behaviour is inexcusable.

BTW, "learn C++" is the answer to every vectorworks limitation, 'cause then you can just write your own CAD program.

Link to comment

I'm not totally clear on what you guys are arguing about or what you are actually saying (95017 ????) but has anyone answered my question yet?

All I am asking VW to do is pick the double line tool, show the setup window and then let me use the tool as normal.

I am guessing from above that you can't do this so utilising your expert VW skills instead of your expert arguing skills can someone give me a suggestion (without being rude).

Maybe this should not be a tool type?

Link to comment

Kool gave you the answer, Brudgy trotted out one of his favorite complaints and I foolishly stepped into the fray. Sorry if it sounded argumentative or rude.

I'm not arguing with anybody.

A vectorscript tool (.vst) won't do anything until you click in the drawing window. This is built into the way Vectorworks plug-ins operate.

Make it a menu command (.vsm) and assign a keyboard short-cut.

Or leave it as palette script and double click that.

Link to comment
The way you defend the tool/command distinction it must come from 95014.

BTW, congratulations. I doubt I could have spelled it out any further.

Actually, it (to your eternal joy) comes from the good old Macintosh Human Interface Guidelines by Bruce Tognazzi et al., which Microsoft has also mainly applied in Windows. Often badly, but nevertheless. That is the basis of all modern operating systems' GUI.

There is, for a good reason, this distinction. As an IT-consultant, a SW developer and a computer user long before your mother was born, I (and my users) appreciate consistency.

What you advocate, is a third UI-concept in the same UI-device. Having trained maybe 200 VW-users in the past 20 years and countless others, even the two present at present (object & tool) are confusing enough.

Setting global operational parameters with a palette tool serves no useful purpose whatsoever. These are, by convention across platforms and programs, accessed with menu commands and dialogs.

Link to comment

If you want an icon to activate it, just live with the extra click.

I often find it less cumbersome than:

1. Burying it in a pull down menu

2. or assigning it an obscure keyboard combination that I'll never remember because I only use the tool five days a year and which requires me to take my hand off the mouse and/or look at the keyboard.

3. Modifying every drawing and template to add it as a script.

Even if some people find the extra click to be sacreligous...

Link to comment

Ahh! And you will remember the brilliantly-designed icon of the command-cum-tool-cum-object and where it is buried in your palettes!

It is of course immensely important that a tool one uses five days a year, is there always.

Whatever, my young friend, whatever?

What else do you have for us in your Lego-piece box frustation?

Link to comment
Actually, it (to your eternal joy) comes from the good old Macintosh Human Interface Guidelines by Bruce Tognazzi et al., which Microsoft has also mainly applied in Windows. Often badly, but nevertheless. That is the basis of all modern operating systems' GUI.

There is, for a good reason, this distinction. As an IT-consultant, a SW developer and a computer user long before your mother was born, I (and my users) appreciate consistency.

What you advocate, is a third UI-concept in the same UI-device. Having trained maybe 200 VW-users in the past 20 years and countless others, even the two present at present (object & tool) are confusing enough.

Setting global operational parameters with a palette tool serves no useful purpose whatsoever. These are, by convention across platforms and programs, accessed with menu commands and dialogs.

How refreshing, I haven't seen someone push PARC down the memory hole all week.

The tool/command distinction may be useful for a programmer...but reflecting it in the user interface is hardly modern practice.

Creating a rigid user interface base on what is convenient for trainers and programmers, well that's just bad design + an excuse.

And the fact that you have to explain the tool/command distinction is evidence thereof.

BTW, it's good to know that the stack layers button "serves no useful purpose whatsoever," despite its obvious utility.

You should add that to your signature.

Link to comment

Ha ha!

PARC developed some UI-devices, not an UI. I knew you'd be ignorant of this, too.

The first designed UI was created by Apple ***************** ****************.

Is the Stack Layers -button in a tool palette?

Anyway, thanks for the laughs once again!

Edited by Pat Stanford
Link to comment

Creating a rigid user interface base on what is convenient for trainers and programmers, well that's just bad design + an excuse.

Get ******-trained first, let's discuss consistency after that. I'll be here in 2020?

Edited by Pat Stanford
Link to comment
Ahh! And you will remember the brilliantly-designed icon of the command-cum-tool-cum-object and where it is buried in your palettes!

It is of course immensely important that a tool one uses five days a year, is there always.

Whatever, my young friend, whatever?

What else do you have for us in your Lego-piece box frustation?

I can rearrange "tool" pallets on the fly for better access...without editing the workspace.

You can't do that with drop down menus or keyboard shortcuts.

Pallets allow the user to expose or hide functionality "at runtime" rather than requiring "recompilation."

(That's a metaphor, just want to spell it out for you).

Link to comment

As I said earlier:

The theoretical tool/command distinction should be independent of the interface used to access...the restriction of the icon interface to tools is inexcusable.

The only reason NNA had to create another (user inaccessible) interface for things like the stack layer command, is because the tool pallet interface is so limited.

Maybe if they weren't so busy chasing their tail patching code for ISO 95014 compatiblity, they could do the needed rewrite.

20 years ago, compiling the UI might have made sense for speed.

It doesn't today.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...