brudgers Posted August 18, 2009 Share Posted August 18, 2009 This tool toggles Black and White only mode. Handy for when your in the middle of something, etc. Because it's vectorscript, you have to click in the drawing to run it. Category "00_pref toggles" Quote Link to comment
Pat Stanford Posted August 18, 2009 Share Posted August 18, 2009 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. Quote Link to comment
brudgers Posted August 18, 2009 Author Share Posted August 18, 2009 (edited) 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 August 18, 2009 by brudgers Quote Link to comment
Pat Stanford Posted August 18, 2009 Share Posted August 18, 2009 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). Quote Link to comment
Jonathan Pickup Posted August 19, 2009 Share Posted August 19, 2009 i made my black and white only a menu command, and I added it ot my right mouse click so I can access it easily. Quote Link to comment
brudgers Posted August 19, 2009 Author Share Posted August 19, 2009 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. Quote Link to comment
Pat Stanford Posted August 19, 2009 Share Posted August 19, 2009 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. Quote Link to comment
Jonathan Pickup Posted August 19, 2009 Share Posted August 19, 2009 commands are on menus, tools and objects are on tool palettes. if you make it a command, you can add it to a new menu, add it to the right mouse click, or assign it a keydoard shortcut. Quote Link to comment
brudgers Posted August 19, 2009 Author Share Posted August 19, 2009 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. Quote Link to comment
Pat Stanford Posted August 19, 2009 Share Posted August 19, 2009 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. Quote Link to comment
VincentCuclair Posted August 19, 2009 Share Posted August 19, 2009 (edited) .... I use a 3rd party plugin with a keyboard shortcut assigned to the tool/command, no need for clicking...... www.vectorbits.com/VectorBits/free/Entradas/2008/1/5_Toggle_VW_Prefs.html www.vectordepot.com/plug-ins/ > Toggles Edited August 19, 2009 by Vincent C Quote Link to comment
brudgers Posted August 19, 2009 Author Share Posted August 19, 2009 (edited) 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 August 19, 2009 by brudgers Quote Link to comment
Jonathan Pickup Posted August 19, 2009 Share Posted August 19, 2009 Can someone from NNA clarify this area please? is vectorscript limited in the way brudgers says, or is there a clear reason why things are made the way they are. Quote Link to comment
Pat Stanford Posted August 19, 2009 Share Posted August 19, 2009 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. Quote Link to comment
ccroft Posted August 28, 2009 Share Posted August 28, 2009 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. Quote Link to comment
brudgers Posted August 28, 2009 Author Share Posted August 28, 2009 (edited) 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 August 28, 2009 by brudgers Quote Link to comment
ccroft Posted August 29, 2009 Share Posted August 29, 2009 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. Quote Link to comment
David L Posted September 9, 2009 Share Posted September 9, 2009 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: Quote Link to comment
brudgers Posted September 11, 2009 Author Share Posted September 11, 2009 I've got one of these around here somewhere. There are significant differences in the user experience between commands and tools. 3d rotataion may be a tool, and left rear isometric may be a command, but for the user their both just a means to see the model in a meaningful way. Quote Link to comment
Recommended Posts
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.