Changing the height of the event log pane from a script fails

I am trying to write a script that will adjust the various parts of a Script Debugger script window. The code below does change the height of the event log but, whatever figure I use, the event log pane is raised to the top of the window, completely obscuring the editor pane.

Am I doing something wrong?

tell application "Script Debugger"
	tell script window 1
		set event log height to 300
	end tell
end tell

Also, when I select Set Default Script Size & State from the Window menu, I believe I should get a dialog but in fact nothing happens. Is it possible something has got corrupted?

I think you’ve found a bug, with a workaround.

First, the event log has a visible and a height property. Try this:

tell application "Script Debugger"
   tell its script window 1
      set event log visible to false
      set event log height to 200
      set event log visible to true
      
   end tell
end tell

The bug is that if you set the event log height to any value when it’s visible, it fills the script window pane. But it you hide the event log, then set its height then make it visible it works as expected.

Second, when you set the Default Script Size and State from the menu, it gets the script size and state from the frontmost script window and uses that as the new default. So no dialog appears but the change (which is easily tested) is made.

HTH

Aha, that’s clever! Thanks so much for this Ed — it works perfectly.

And I think I must have been looking at some out-of-date documentation about the Default Script Size & State, it does indeed work as you describe.

Glad it helped. As for documentation, stick with the Script Debugger Help. It’s one of the best application documentations I’ve ever seen. This page: “Default Script Window Size and State” fully describes that feature.

It’s indeed a great resource.

Regarding an app’s help there’s something very useful (at least for me): If you’re a DEVONthink user then you might want to index a copy of a given app’s help. For me it’s far more comfortable to do a DEVONthink search than trying to find what I’m looking for in macOS’s help viewer. The basic idea can be found in this post, a script that indexes (a duplicate of) DEVONthink’s help is here.

The expandable outline form of the SD help table of contents is pretty handy.

I’m not a DEVONthink user, but I agree with you about the issues searching Apple Help. I have written an appleScript that duplicates SD’s help, and allows you to search it (using the BBEdit application) and displays the results as a page of links to the help pages that displays in your browser.

I’d be happy to share if anyone is interested. It runs from the menu bar and stores its data in Application Support. It also updates its files when there’s a new version of SD available.

Sounds interesting. I’d like to see how you did that.

SearchSDHelp.app.zip (351.1 KB)

So here it is, an App. A few notes. I think you’ll have to open it in SD and save it as an app in order to use it. (it’s not code signed or notarized, and it’s not run-only).

It has three libraries in its library scripts folder. Two of Shane’s and one of mine that I"borrowed" from Nigel and now use all the time (Thanks @ShaneStanley and @NigelGarvey!).

The help files and the searchable text files will be copied to the applet’s resources folder the first time you run it. After that each time it runs it just works with those files, until you upgrade to the next version of SD. When you do that, the first time you run a new version of SD, it will copy and format a new set of files. That takes about 3 minutes OMM, and after the first run it’s quick. YMMV)

It’s using BBEdit to do a simple operation that I should do with RegEx or GREP, but I’m not there yet. Essentially it finds the term in the text file, gets the address for the HTML file, puts the paragraph with the search term into a results file, with links to the HTML. When it’s run a new Chrome window will open with the results page, telling you how many instances were found, and all the instances on each page are nested together under the pages’ header. You can open the page clicking on the linked term or the header. (Haven’t figured out how to make it take you directly to the found term in context)

Past searches are linked to at the bottom.

Since each search you do gets saved whenever you repeat a search for the same term it opens lightning fast.

Lemme know what you think or if you have any suggestions. If you make any improvements, feel free to share back!

That works very nicely and impressively. Thank you!

EDIT: And yes, I had to open it in SD and save it. I tried using xattr -rc to un-“damage” it, but couldn’t get permission to apply the command to main.scpt. It opened and saved inside SD perfectly. Thank you again.

1 Like