Jump to content

Lee C.S. Young

Member
  • Posts

    8
  • Joined

  • Last visited

    Never

Everything posted by Lee C.S. Young

  1. It sounds like you are attempting to edit a plug-in and not a script. Plug-ins are not plain text; they are binary and can not be edited with a text editor. (Well, that's not entirely true but it's neither here nor there.) In order to edit a plug-in, you'll need to use VectorWorks' Plug-In Editor and the plug-in must not be encrypted. What do you mean by 'Standard VW scripts'?
  2. Files on the Mac are recognised via file types and creator codes. (Well, they were in Mac OS 9 and earlier, I?ve moved away from Mac since then so I am not sure about Mac OS X). As you know, file types in Windows are recognised via a file extension. For your plug-ins, simply amend the appropriate file extension to the filename if it does not contain one. (Check to make sure that you are not hiding file extensions in Explorer first.) If the plug-ins are your own and are not encrypted, you?ll be able to open them via the Plug-In Editor in VW. Scripts on the other hand, since they are not stored in binary format but are plain text, should be editable with your favourite text editor. If you have not done so already, add a file type of .vss through Explorer and assign the files to open with your text editor. There should not be a reason that plug-ins created on the Mac do not run in Windows provided any scripts that access external files use the Windows style file path delimiters. Even if the delimiters are Mac style the script/plug-in should return an error when accessing an external file when run on Windows. One thing to note: Plug-ins created on the Mac through the Plug-In editor/Script Editor should in fact still have the file extension as part of the filename. I personally ?converted? (for lack of a better word) hundreds of plug-ins without an issue. Good luck.
  3. Kees, take a look at the link I posted; the dialogs are not following the design guidelines, which is the issue in the first place. [edit] Anyway, I'm not trying to beat up on NNA here. I'm far from an expert in GUI design and implementation. I'd just like to go back to the efficient dialogs. Thanks for listening.[/edit] [ 03-30-2004, 11:15 AM: Message edited by: Lee C.S. Young ]
  4. I have more issues with the GUI but those (for the most part) I can live with. Ray, zero: hitting enter on the keyboard dismisses the dialog no matter what control is active. So changing each dialog to follow proper behaviour would not affect what you are used to.
  5. I still have issues with two dialogs that I use often in VW. One being the duplicate array and the other being the move dialog. These two dialogs are not following the logical flow of the usage of the dialogs, and are breaking both Apple's and Microsoft's design guidelines. The Duplicate Array Dialog This dialog opens with the active control being the OK button. Why? The dialog should focus on the most commonly used control, and in this case, I would most likely be correct in assuming that would be the edit fields for the amount of offset. The dialogs tab order (and perhaps the layout) should be taken a look at and reassessed. The Move Dialog This dialog I have real issues with. The active control is the OK button. The next tab brings you to the Cancel button. Next tab brings you to the Radio button. Finally you are taken to the first edit field. This means it takes three presses of the tab button to get to the most commonly used control. Shouldn't the move dialog used to move an object quickly? I've emailed this to both tech and bugsubmit before 10.5.1 was released, (without a response) and while the clean up on the Duplicate array dialog was a start, would someone over at NNA please take a look at this? Thank you.
  6. Not sure if it has been brought up, but can the application follow a standard that has been set for years? Double click to edit text.
×
×
  • Create New...