sketchucation logo sketchucation
    • Login
    πŸ€‘ SketchPlus 1.3 | 44 Tools for $15 until June 20th Buy Now

    Workflow for script coding and testing

    Scheduled Pinned Locked Moved Developers' Forum
    3 Posts 2 Posters 207 Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • U Offline
      UserQuestion
      last edited by

      This question is about the workflow for crafting Sketchup Ruby scripts.

      I have no problem installing others' scripts, or with programming. What has me at a loss is how to craft a script and make iterative changes, with intervening runs/tests.

      In basic, VBA, fortran and so on, I could make an immediate run, and modify a program. But with SU2013, and the RBZ that is installed from one location into the SU Program Plugin Folder, I get tangled:
      a. having to modify the folder name from Zip to RBZ, just to make edits, and back again
      b. making edits of RB scripts in what I call the myProject area, to install afterwards using the SU2013 extension installation schema
      c. not seeing a simple way to uninstall an extension, and then install the modified version
      d. not recognizing a way to use a RB menu script to create a Toolbar and Icon which would call a script which installs or uninstalls the script being worked on

      I thought there might be a way to just create a "run/install script icon", hit that button to run/install, see what happens, edit the script using notepad++, and hit the button again to test...and so on.

      I haven't found a workflow URL for this process in the SU documentation at Trimble/Google, and the SU extensions I've opened provide good clues/hints for coding, but don't help with how I can make the workflow for coding/testing/coding/testing...work.

      Can anyone provide some pointers to good URLs, or what you consider good sample extensions that show off what I'm trying to do?

      Thanks

      1 Reply Last reply Reply Quote 0
      • Dan RathbunD Offline
        Dan Rathbun
        last edited by

        So anyhow, what I do (if I am not using Github or SVN, etc.) is make a local repo folder in the plugins folder, usually named "project"

        ... beneath that are various project plugins folders as they would be named when they eventually are installed into the "Plugins" folder by the SCF Tools installer, the built-in install from Archive button, or Trimble's ExtensionWarehouse.

        IF you write a SkecthupExention registration script for the project, it would go temporarily in the "project" folder, instead of the "Plugins" folder.
        (So everything is removed one level down into the "project" hierarchy.. get it?)

        Since you are in development, you do not need to have SketchUp do the startup load via extension early on... you will load manually from the Ruby Console command line.

        Start SketchUp... open the Console... and assuming your project folder name is "User_Widget" and it's loader file is named "widget_loader.rb".. you would type:
        load "project/User_Widget/widget_loader.rb"

        If any errors are output.. note the filename and line in the first error message, ALT+TAB back to Notepad++, make changes to the code, resave the file... ALT+TAB back to SketchUp... and reload.

        I often use Jim Foltz' Ruby Toolbar that remembers the last file loaded, and assigns it to a button.

        There are also a few WebDialog based editor / utilities that can also make it easier to reload files.

        πŸ’­

        I'm not here much anymore.

        1 Reply Last reply Reply Quote 0
        • Dan RathbunD Offline
          Dan Rathbun
          last edited by

          (1) If you are going to develop, logon as an admmistrator, so you have full access rights to the plugins folder. (Or right-click the SketchUP icon, and choose "Run As Administrator", or "Run with elevated Privileges" etc.)

          (2) Forget about zip & rbz during development, that is the avenue of distribution.

          (3) Stop thinking of SCRIPT, and start thinking of your code as being defined WITHIN and executing FROM your namespaces. You need to choose a toplevel namespace (module name,) and then write ALL of your plugins within a sub-module of your toplevel module. (Clarify: I mean each plugin has it's OWN sub-module of your toplevel author/company module. That way NONE of your plugins clash with each other, NOR any other author's plugins.)

          (4) BE wary of comparing Ruby to Fortran, BASIC, etc. Ruby is MUCH different. It is a dynamic language. This means that modules and classes can be modified at any time. Methods can be redefined, removed, access changed (made private,) etc.
          This also means you can reload a file that defines your plugin's module, after making changes, and the changed methods are updated. This is great for development.

          (5) Ruby is 100% object-oriented. Ruby has 2 (TWO) things. Objects and references that point at objects. Ruby does not really have variables, but the documentation and some query methods refer to "variables", but I think it is best to have programmers from other languages know from day one, that Ruby only has references, not variables like BASIC.
          For example, Ruby references can point at any object, at any time, of any class, and then be changed (re-assigned,) to point at any other object, of any other class (or perhaps the same class.)
          So any "typing" of reference names is only in your mind. It it makes you "comfy" to say use bMyRefName to hold a reference only to true or false (or nil,) then thats OK.

          Add

          (6) Read the "Pick-Axe" Ruby book cover to cover. (see the Ruby Resources sticky topic.)
          Doing so will make your journey so much easier, and avoid asking all the questions here that people who do not read the book first have already asked (here and in other forums.)

          (7) Do not think or write your code in a linear manner. Think in and write code in an event-driven manner. (Have your code respond to things the user does, or act upon objects the user has selected, or do something with the entity the user has just modified, etc.)
          See the API dictionary on all the observer classes.

          πŸ’­

          I'm not here much anymore.

          1 Reply Last reply Reply Quote 0
          • 1 / 1
          • First post
            Last post
          Buy SketchPlus
          Buy SUbD
          Buy WrapR
          Buy eBook
          Buy Modelur
          Buy Vertex Tools
          Buy SketchCuisine
          Buy FormFonts

          Advertisement