Jump to content

Tool: toggle Black White Only mode


Recommended Posts

Just a slight correction. Because it is a Plug-in Tool rather than a Plug-in Command you have to click in the drawing.

It is probably better to make these types of scripts into commands and put them in a submenu (and/or assign then keyboard shortcuts) rather than make tools out of them so it requires an additional click.

Link to comment

I understand the theory.

But if the user can't see it, then it doesn't really exist.

I don't know if you've bothered to look at the videos regarding the microsoft ribbon, but they really shed light on the problems of "conventional" user interfaces...even if you don't think that the ribbon is better than a poke in the eye.

Making it a tool replaces File->Document Settings-->Document Preferences--->[tab] Display---->Black and White Only----->OK.

Not to mention that the user might look under Tools->Options-->VectorWorks Preferences--->[tab]Display----->etc. first.

In my opinion, the extra click is a result of shortcomings in the implementation of Vectorscript. Commands don't have icons, if you need an icon it has to be a tool...that's a limitation of vectorscript.

The extra click is unappealing but a more user friendly kludge than forcing the user to remember the location of a radio button four layers deep or an arcane ctrl+shift+W sort of thing.

Tools allow the user to reveal functionality at their pleasure. And in a multi-user environment, "push this button" can save a lot of time and heartache.

BTW, toggle B/W was just something that was simple to create an icon for...unlike show other objects in groups, it's not generally all that useful.

Edited by brudgers
Link to comment

Brudgers,

Two things.

1. I just want to make sure that people reading this thread are clear on what the limitations are. The extra click is due to the type of object you made it, not that it is a Vectorscript. Tools require a click in the drawing. Commands do not. It sounds like you like a button based interface. I am sure there are many others who would as well. Unfortunately, VW does not currently offer that functionality.

2. If you need an Icon, then what you are doing is the only way I know of. There is another way and that is to create a Script Palette (or more than one) and put all the scripts in there. To run the script then requires a double click instead of a click on the tool icon and then a second click in the drawing.

None of the scripts you have posted as tools need to be tools. It is just a choice. If you want them as scripts (or maybe even menu commands), you can get a download from VectorDepot.com. Search on Toggle.

The basic code for changing the state of most of the preferences is something like

SetPref(N, NOT GetPref(N));

Where N is the Preference Selector for the pref (usually found in the VectorScript Appendix in the VW Help).

Link to comment

Pat,

The major design decision was regarding the interface not the program structure.

I didn't choose to make a tool out of the code, I chose to run the code from an icon and was therefore forced to structure it as a tool.

That's a result of vectorscript's limitations...though I suppose it's possible others may see this as much needed inflexibility and an indispensible feature.

Jonathan,

I've used the context menu, the problem is that I (like many others I expect) use certain features of the software more intensively at some times and less intensively at others.

The context menu simply becomes unwieldy with everything that I might need at my fingertips. Back in the old days, AutoCad used to have menu swapping to handle this sort of thing, but so far as I know, vectorworks lacks this sort of automation feature.

Currently, tool sets offer the best alternative across multiple documents.

Link to comment

If it works for you then great. But you know you are using a work around. My point (and I think Jonathan's) is that there are other ways to do this rather than try to force the interface you want onto a program that was not designed for it.

But as I mentioned to someone else, let's not create false rumors about the limitations of VW (e.g. that because it used VectorScript it requires a click in the drawing). There are enough real limitations to deal with without making more.

Link to comment

Pat,

Vectorscript is limited in the way it can be executed by the user interface. Just because the limitation is documented, doesn't make it any less of a limitation.

The fact that NNA has drawn a distinction between tools and commands doesn't mean that it's a good approach either.

A tool's screen click is no more a compromise than limiting a command to the menu system, even if one is officially endorsed...and sometimes I think Vectorworks may be German for "workaround."

Jonathan,

Yes, yes... but I wanted an icon.

Link to comment

Brudgers,

Last time.

VS is limited in what it can do and how it can do it.

VW is limited in what it can do and how it can do it.

You know what the limitations are and have a work around that works for you. That is good.

I don't mind acknowledging the limitations. I do mind blanket statements that can confuse others like:

Because it's vectorscript, you have to click in the drawing to run it.[/Quote]

Vectorscript tools and objects require a click.

Scripts run from a menu command, a script palette or a contextual menu do not.

I prefer to be explicitly clean on the limitations and to offer alternative ways of doing things.

Link to comment
Brudgers,

Last time.

VS is limited in what it can do and how it can do it.

VW is limited in what it can do and how it can do it.

You know what the limitations are and have a work around that works for you. That is good.

I don't mind acknowledging the limitations. I do mind blanket statements that can confuse others like:

"Because it's vectorscript, you have to click in the drawing to run it."

Vectorscript tools and objects require a click.

Scripts run from a menu command, a script palette or a contextual menu do not.

I prefer to be explicitly clean on the limitations and to offer alternative ways of doing things.

It's already accessible through the menu system, so that's not an alternative implementation.

Placing it in a script pallet limits its scope to a single file, so that not an equivalent implementation.

My specification was similar to: Need "command" script to behave like a "tool" and for multiple users.

The extra click is a compromise imposed by the limits of Vectorscript. In other words, because it's vectorscript, you have to click in the drawing to run it.

Given the specification, placing the functionality in a menu command or script pallet is a work around, the extra click is a result of vectorscript being unable to meet the specification cleanly.

As far as I can see, there's no advantage to limiting what can be executed cleanly by icon (other than fewer coding hours in Baltimore).

The tool/command split has no benefit to the user. Indeed, given the doctrinal limitations it places on implementation, it is primarily to the user's detriment.

It would be most unfortunate if my lack of enthusiasm for dogma upset you.

Edited by brudgers
Link to comment

I'm not from NNA, but I can confirm that tools require a click in the drawing area to activate the script.

Brudgers is trying to use a Tool Palette as a set of buttons to launch scripts. Would that be a nice thing to have? Yes. Does it currently exist? No.

In the mean time you need to use a script or a command or deal with the extra click if you want "buttons" with icons.

Link to comment
  • 2 weeks later...

Haven't been in here for a while so I'm a little late to the discussion. This limitation is part of the architecture of vScript, as stated above. There are 4 types of vScripts, 3 of which are decided when you create a Plug-in. I understand it as follows:

.vst??????VectorScript Tool???????for working in the drawing window IE drawing things

.vso?????VectorScript Object????for placing a parametric object

.vsm????VectorScript Menu?????for everything else

So since VST has been designed for working in the drawing window it requires you to click there. If you wish to do something that doesn't involve the drawing window then your script should be implemented as VSM.

If your menus are getting too cluttered it's time for a visit to workspace editor, where you can create a new menu in the bar called for EG Preference Toggles. This will allow you to access these much more easily, without drilling down thru the built in preference dialog.

As for context menu, you can add the new 'Toggle' menu and the enclosed scripts will cascade out from 'Preference Toggles'. This takes up one line in the context menu. Further, you can set it so that it only shows when you right-click in a blank area. And that also makes some sense, since you aren't trying to edit an object in the drawing window.

The closest thing we have to a button activated VSM is the palette script. The palette can be put into a template so the scripts are available in every new drawing. They require 2 clicks to run, just like a command script implemented as a VST, but they're in the same place instead of one on the icon and one in the drawing window.

Not saying this is the way it 'should be'. It's just the way it currently is.

Link to comment

In my opinion, the part that isn't as it should be is mapping underlying function to specific methods of interfacing.

Setting aside a debate about the necessity of packaging some code as tools and other code as commands, there is no reason each is limited in the way they can be initiated.

As the icon shows, there are not design issues running a command from an icon. The issues solely arise from the specific ways in which buttons are implimented in vectorworks.

Just making a wild guess, it probably has much more to do with Mac resource forks and history rather than with interface design for user benefit.

Edited by brudgers
Link to comment

There is no 'real' reason, but it's pretty much the same in all major graphic apps.

Maybe you're right about Mac history since all these were developed on Mac. There's probably some 'Best Practices' paper from the late 80's floating around suggesting this architecture.

On the bright side we do, however, get the tool behavior for 'free', since we don't have to write anything that looks for an interaction in the drawing window. Much like we get a dialog for next to nothing with .vso thru the OIP.

Just don't forget that our beloved vScript is not a full-fledged programming language and has limitations (as well as pay-offs). You can probably do what you want with SDK.

Link to comment
  • 2 weeks later...

There are 4 Preference settings I use constantly (20-50 times a day). I created Plug-in Command toggles and assigned them to the F-keys using QuicKeys. I still can't believe Graphsoft/Nemetschek has not added the ability to assign commands and tools to the F-keys, after all these years.

I have 72 commands mapped to the F-Keys on my 19 F-key Mac keyboard. Plus most of the tools and another 60 commands to other key combinations. Yes it sounds obsessive but I've been using it for 15+ years and it is a huge time saver. Check it out:

VW Keyboard Template.png

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...