Editing An Entire Project

[cmclane]

Is there a utility, or a strategy, for moving systematically through an entire project and finding things that need to be changed and changing them? With SuperEdit it appears that I would have to move object by object (Project; Backgrounds & Cards in the Project; Fields, Buttons, etc. on each card) - - one at a time - - and search that object's script. From the description in the User Guide, and from testing it out, it appears that SuperScript will print out the entire project (as text or RTF), but I can't see a way to edit that and get it back into SuperCard.

I tried just opening a copy of the project using TextEdit, and making a few simple edits, and then saving the file. But when I tried to run it again in SuperCard I got a checksum error.

The best thing I could come up with is to use Project Search, but to do that I would need to know what I need to search for. I guess I could get this from visually inspecting the entire project printed out as a text file from SuperScript - - and then do my searching and editing or replacing in Project Search.

Does that sound like a reasonable approach, or am I missing something obvious that would be easier?

[jen...@adelaide.on.net]

Hi Charlie

I would export all the project's scripts as text using SuperScript.

Then you can look through the text file and make your changes, saving the text file as you go.

The SuperScript export identifies where each script has come from.

For example:

----------------------------------------------------------------------------------------------------------------

WD #2 CD #28 OF BG #1 (CARD #28)

PART #5 BTN #3 ID 105: Albums

----------------------------------------------------------------------------------------------------------------

So if you have changed that particular script, then when you want to replace the old script with your new one, you can open the project in SuperEdit, go to card #28 in background 1 of window 2, open the script of card button id 105 (named "Albums"), copy the modified script from the text file, paste it in and save.

I use BBEdit as my preferred text editor.

It has a nice feature where you can find differences between two text files.

So if you have the original set of scripts in one text file and you edit the scripts in a second text file being a copy of the first, you can easily check what changes you have made.

Peter Jenkins

[Vince]

Some programming text editors allow you to add "TODO" comments to your code and then run a script to "Find TODOs" and it gives you a list of the to-do items in your code.(I think Textmate does this) I don't think this would bevery difficult to script in SC, possibly adapting the Superscript code to just show you scripts where you have included TODO in the comments. That would provide you a smaller pile of text to plow through.

Vince

[Charles McLane]

Peter that sounds like a much better method - - i.e. making the edits in a text editor (I will give BBEdit a try) and then using SuperEdit for the simpler part of just pasting them back in where a script has been changed. Thank you.

--
You received this message because you are subscribed to a topic in the Google Groups "SuperCard Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/supercard-talk/CSQNNQP57Ek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to supercard-talk+unsubscribe@googlegroups.com.
To post to this group, send email to supercard-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/supercard-talk/7359f5b8-8d20-48dd-95c8-f39599aae8d1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Charles F. McLane III, PhD

Principal

707 Alexander Road, Suite 206 - Princeton NJ 08540

Direct: 609-919-2701  Fax: 609-987-8488

Email: cmc...@mclaneenv.com

[Charles McLane]

That is a good suggestion Vince. When I get into the editing part I can think about possibly writing a SC script to aid the process - - but even if I don't go to that step your suggestion of flagging the changed script sections with "TODO" or "CHANGED" or any identifying text string will let me find them easier and will help me walk through the long project file and find the edited scripts I need to plug back into the project. Thanks.

--

You received this message because you are subscribed to a topic in the Google Groups "SuperCard Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/supercard-talk/CSQNNQP57Ek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to supercard-talk+unsubscribe@googlegroups.com.
To post to this group, send email to supercard-talk@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/supercard-talk/b06652fb-b8b7-497f-924c-8767c4596527%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Scott]

I have wanted something like this for some time. We've talked about it, but the issue was always how to delimit the various scripts in a single file. Now that SuperCard can generate UUIDs that is probably a good way to do it.

But in the meantime I woofed up this project which exports all scripts to text files, and then reimports them back to a project. No really heavy testing here other than running on a few of the more complex projects I have, and then running a Diff on the scripts after reimporting. Seems to work fine.

Note only objects whose scripts are not empty generate text files.

Enjoy!

[codegreen]

FWIW as posted this nifty little widget has a couple of minor issues:

- It throws a scriptError if the target project has no windows, or if its first window has no cards

- It writes WAY too many redundant status messages (and to the most expensive possible place)

- It opens and closes the target project for every script it exports/imports

You're unlikely to run into #1 very often in the real world, but it's easy enough to avoid.

You won't feel much pain from #2 and #3 if your project exports only a dozen scripts, but after that they'll start to hurt...

Here's a simple mod that demonstrates how to avoid them all:

on exportTheRest

  global gProjectToExport

  put the long id of cd fld 1 into theField

  push cd

  lock messages

  put "Writing scripts, please wait…" into cd fld 1

  try

      open inv wd 1 of proj gProjectToExport

    catch tError

      switch tError

        case 53

          alert "First project window contains no cards!" explain "Exporting won't work unless there's at least one..."

          pop cd

          put "Export failed!" into cd fld 1

          unlock messages

          exit script

      end switch

  end try

  repeat with w = 1 to the num of windows

    get exportScript(the long id of wd w)

    repeat with b = 1 to the num of backgrounds of wd w

      get exportScript(the long id of bg b of wd w)

      repeat with p = 1 to the num of parts of bg b of wd w

        get exportScript(the long id of part p of bg b of wd w)

      end repeat

      repeat with c = 1 to the num of cards of bg b of wd w

        get exportScript(the long id of card c of bg b of wd w)

        repeat with cp = 1 to the num of parts of cd c of bg b of wd w

          get exportScript(the long id of part cp of cd c of bg b of wd w)

        end repeat

      end repeat

    end repeat

  end repeat

  repeat with m = 1 to the num of menus

    get exportScript(the long id of menu m)

    repeat with i = 1 to the num of items of menu m

      get exportScript(the long id of item i of menu m)

    end repeat

  end repeat

  close proj gProjectToExport

  pop cd

  put "Export complete" into cd fld 1

  unlock messages

end exportTheRest

Run on the SuperCard Help project (which exports 111 script files) this version is over five times faster here.

I'll leave more robust error-checking and retrofitting these tweaks to the import handler as an exercise for the gentle reader...

-Mark

[codegreen]

Here's a couple of additional tweaks to further reduce overhead. Together they make this now average well over 8 times faster than the original here:

on exportTheRest

  global gProjectToExport

  push cd

  lock messages

  put "Writing scripts, please wait…" into cd fld 1

  try

      open inv wd 1 of proj gProjectToExport

    catch tError

      switch tError

        case 53

          alert "First project window contains no cards!" explain "Exporting won't work unless there's at least one..."

          pop cd

          unlock messages

          exit script

      end switch

  end try

  repeat with w = 1 to the num of windows

    get the script of wd w

    if it ≠ empty then exportScript the long id of wd w, @it

    repeat with b = 1 to the num of backgrounds of wd w

      get the script of bg b of wd w

      if it ≠ empty then exportScript the long id of bg b of wd w, @it

      repeat with p = 1 to the num of parts of bg b of wd w

        get the script of part p of bg b of wd w

        if it ≠ empty then exportScript the long id of part p of bg b of wd w, @it

      end repeat

      repeat with c = 1 to the num of cards of bg b of wd w

        get the script of card c of bg b of wd w

        if it ≠ empty then exportScript the long id of card c of bg b of wd w, @it

        repeat with cp = 1 to the num of parts of cd c of bg b of wd w

          get the script of part cp of cd c of bg b of wd w

          if it ≠ empty then exportScript the long id of part cp of cd c of bg b of wd w, @it

        end repeat

      end repeat

    end repeat

  end repeat

  repeat with m = 1 to the num of menus

    get the script of menu m

    if it ≠ empty then exportScript the long id of menu m, @it

    repeat with i = 1 to the num of items of menu m

      get the script of item i of menu m

      if it ≠ empty then exportScript the long id of item i of menu m, @it

    end repeat

  end repeat

  close proj gProjectToExport

  pop cd

  put empty

  put "Export complete" into cd fld 1

  unlock messages

end exportTheRest

on exportScript tLID, theScript

  global gSavePath, gProjectToExport

  put gSavePath & replace(tLID, space & quote & gProjectToExport & quote, empty) & ".txt" into tFile

  open file tfile

  write theScript to file tfile

  close file tfile

end exportScript

If we were talking the difference between a tenth and three quarters of a second I wouldn't care, but even on an SSD for the SC Help project here these little optimizations mean the difference between 1.75 and 14.25 seconds just for the export step alone.

Ya save a nickel here and a dime there, and I guess after a while it adds up... ;-)

HTH,

-Mark

[cmclane]

Scott and Mark,

Thank you for creating this project. It sounds like it is going to be very helpful for what I am trying to do. But initially I can't get it to work; it's probably something I have done wrong.

I downloaded the ScriptTransfer project that Scott created, opened the project script, deleted the original exportTheRest handler script, and replaced it with the text from Mark's second post (i.e. what I assume is the latest version of his code tweaks).

I then ran the project and began the process of exporting scripts. I selected a project file to operate on, and then I selected a folder into which to place the exported script files. At that point the transfer started to run, but almost immediately I received an error message that read "SuperTalk Error Number 1: Never heard of that handler."

I clicked on the Script button, which displayed this script:

on mouseUp

global gSavePath, gProjectToExport

answer file "Select the Project to export scripts from:" with extension "sc45"

if it is empty then exit mouseup

put it into gProjectToExport

answer folder "Select a folder for the exported scripts (text files)"

if it is empty then exit mouseup

put it into gSavePath

exportProjectScript

exportTheRest

end mouseUp

and the cursor was located in front of the second to last line "exportTheRest".

When I checked my output folder I saw that the file "project.text" was there, so that part worked fine.

Please let me know if you have any thoughts on how I can get this running properly. Thanks.

- Charlie

If we were talking the difference between a tenth and three quarters of a second I wouldn't care, but even on an SSD for the SC Help project here these little optimizations mean the difference 1.75 and 14.25 seconds just for the export step alone.

[Scott]

You sure you didn't paste over the handler name. If any doubt just download the project again. It works just fine, just slower than Mark's handler.

[Charles McLane]

Scott, I tried your project and it works fine. It opened and exported all of the scripts for the SampleDraw project in 2 or 3 seconds.

Just because I am stubborn I went back and tried to get Mark's tweaks to work in a copy of your project with no success (but it's probably just me). I noticed that Mark's tweaks have the following handler:

on exportScript tLID, theScript

  global gSavePath, gProjectToExport

  put gSavePath & replace(tLID, space & quote & gProjectToExport & quote, empty) & ".txt" into tFile

  open file tfile

  write theScript to file tfile

  close file tfile

end exportScript

whereas your project script has this as a function. I tried pasting Mark's text over your function and changing "on" to "function" but the tweaked version of the ScriptTransfer project still gives the "Never heard of that handler" error for exportTheRest. I can't get it to work but I'm moving ahead with the files I created using your project. Thanks again.

- Charlie

On Sat, Jun 30, 2018 at 8:21 PM, Scott <scottin...@gmail.com> wrote:

You sure you didn't paste over the handler name. If any doubt just download the project again. It works just fine, just slower than Mark's handler.

--
You received this message because you are subscribed to a topic in the Google Groups "SuperCard Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/supercard-talk/CSQNNQP57Ek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to supercard-talk+unsubscribe@googlegroups.com.
To post to this group, send email to supercard-talk@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/supercard-talk/50aab242-b7a4-45ea-a7b2-aee1b0f92cbe%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Scott]

BTW, BBEdit has a multi file search and replace function so it should be easy to swap out those variable names.

[codegreen]

For future reference, there's no problem with having a handler and a function with the same name.

In a case like this, to test the revised scripts what I'd do first is open the original project, open the msg box, type copy cd and hit return, then paste cd and return.

Next press Control-C to open the card script, and paste in the scripts in my last post.

Now you can test the updated version using that card (i.e., card 2) and the original by going back to card 1.

This way it's tougher to break something, and if you do to figure out why...

-Mark

[Charles McLane]

Thanks for the tip. I just downloaded a copy of BBEdit and was reading the User Guide about multi-file search and replace. That is going to make things much easier (AND less error prone).

On Sat, Jun 30, 2018 at 8:59 PM, Scott <scottin...@gmail.com> wrote:

BTW, BBEdit has a multi file search and replace function so it should be easy to swap out those variable names.

--
You received this message because you are subscribed to a topic in the Google Groups "SuperCard Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/supercard-talk/CSQNNQP57Ek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to supercard-talk+unsubscribe@googlegroups.com.
To post to this group, send email to supercard-talk@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/supercard-talk/428bc2a0-1a4b-4c1e-993b-73a7f460b05a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[codegreen]

BTW if (for legibility) you'd prefer to export scripts with indenting there's an XFcn called IndentScript() in the ClickScript RTE utility project that you can use to add standard indenting, then strip it out again when reimporting.

HTH,

-Mark

[Charles McLane]

I followed your instructions and it worked. I now have two cards - - Card 1 with Scott's scripts in all locations, and Card 2 with your scripts at the card level intercepting messages intended for what Scott originally wrote in the Project Script. So it works, but having multiple handlers with the same name in different locations doesn't sound like a good idea to me. I should be able to move your card scripts out of the card and into the Project Script and then delete your card scripts. I'll try that tomorrow.

--

You received this message because you are subscribed to a topic in the Google Groups "SuperCard Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/supercard-talk/CSQNNQP57Ek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to supercard-talk+unsubscribe@googlegroups.com.
To post to this group, send email to supercard-talk@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/supercard-talk/df936537-271d-4ae3-ac09-b2b2ff33cbca%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Charles McLane]

Thanks Mark - - I'll take a look.

--

You received this message because you are subscribed to a topic in the Google Groups "SuperCard Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/supercard-talk/CSQNNQP57Ek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to supercard-talk+unsubscribe@googlegroups.com.
To post to this group, send email to supercard-talk@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/supercard-talk/ee7e978c-18f8-42eb-883b-77b3dd0ba34f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[codegreen]

On Sunday, July 1, 2018 at 12:09:49 AM UTC-4, cmclane wrote:

So it works, but having multiple handlers with the same name in different locations doesn't sound like a good idea to me.

Though it may 'feel' wrong at first, FWIW this is actually an extremely common design pattern in event-driven programming. You need to learn to not just recognize but accept and embrace it.

When done judiciously it lets you leverage the object hierachy to simplify writing clear, concise, efficient, modular, and maintainable code (in no small part because as demonstrated here it helps reduce collateral damage when making changes). 

If and when you actually decide to permanently consolidate things to use optimized versions, you can move them from the card script of the testing card to the project script. But for now at least with this setup you can still step through both as you tweak the rest of the code to use these optimizations, both to benchmark your changes against the original and because having this kind of frame of reference usually makes it MUCH easier to grok what's wrong if you make a mistake.

Stop and think for a moment about the fact that you just added (and tested head-to-head) updated versions of multiple core routines in the original project without having to change a SINGLE LETTER of the original code, and how much more difficult and error-prone that process would've been if you'd had to somehow manage it procedurally.

-Mark

[Charles McLane]

Mark, I hear you on this, and I think I understand what you are saying. And I see how this could be useful for a Jedi scripter (I'm looking at you) who lives and breathes the project structure paradigm and how the message passing hierarchy can be leveraged in a particular project. And I will keep this advice in mind, and work toward it, and maybe get there someday step by step.

But when I know that I have a "on doThatThing" handler at one level and another different "on doThatThing" higher up, and I make a "on doThatThing call deep down in the project on one button of one card in a particular window, and I have to keep track of whether I meant the handler on the card or the one in the window or the one at the project level I guarantee you at my level of scripting prowess I will screw that up.

I copied your tweaks into Scott's original project and it is now running. My mistake was not recognizing that a handler can take arguments; so last night I had tried to convert your 'exportScript" handler to a function. Anyway I have Scott's original project which runs, and your souped-up version which runs 7 to 8 times faster (which is not an issue for me now, but who knows for future uses), so I am good to go either way. Thank you very much for your help.

--

You received this message because you are subscribed to a topic in the Google Groups "SuperCard Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/supercard-talk/CSQNNQP57Ek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to supercard-talk+unsubscribe@googlegroups.com.
To post to this group, send email to supercard-talk@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/supercard-talk/ee186277-4c1b-4e6d-9e3d-2012603a94ef%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[codegreen]

On Sunday, July 1, 2018 at 3:15:44 PM UTC-4, cmclane wrote:

And I see how this could be useful for a Jedi scripter (I'm looking at you)

LOL! Well then to pursue that dubious analogy further, mastering the object hierarchy is to a Jedi Scripter as mastering The Force is to a Jedi Knight.

The most powerful tool in SuperTalk, yet invisible it is...

;-)

-Mark