DSP Robotics Support

Thanks Nubeat !

Nubeat7 wrote:welcome back Mr Trogluddite !

Hi there! Glad to see that you're still around, too. And I liked your little summary of the Ruby gizmo's that you've been working on - I missed a lot interesting stuff while I was away!

No modules in this post, I'm afraid, just a little Ruby code snippet that I've found handy when working with
messageBoxes.

Usually, when creating a messageBox via Ruby, an ID has to be given; and when it returns, you check the ID and do whatever with the reply within the messageBoxFinished method. This can get a bit messy for a RubyEdit which has more than one reason why it might open a message box. Hence the following neat little solution...

Firstly, copy and paste these method definitions into the RubyEdit...

Code: Select all

def messageBox(message, title = "FlowStone", type = nil, &callback)
    type = 'ok' if !type || type.empty?
    @messagebox_callback = callback
    super(callback.__id__, message, title, type)
rescue StandardError
    @messagebox_callback = nil
    raise
end

def messageBoxFinished(id, reply)
    if @messagebox_callback && id == @messagebox_callback.__id__
        @messagebox_callback.call(reply)
    end
ensure
    @messagebox_callback = nil
end

This changes the messageBox method (for this RubyEdit only!) so that you now call it like this...

Code: Select all

messageBox(message, title, type) do |reply|
    # The code in here runs when a messageBox button is clicked.
    # For example...
    watch("How kind of you to agree!") if reply == 'ok'
end


The message, title, and type arguments are all the same as before (including title and type being optional); but the ID argument isn't needed, and a code block is given to determine what will happen when the messageBox closes - the code block is passed the String label of the button which was clicked (all lower-case).

This has a couple of advantages. Firstly, no matter what you use the messageBoxes for, you'll never have to edit messageBoxFinished again - every messageBox can have its own unique callback code without needing a load of decision making done when the messageBox closes. Secondly, there's no need to worry about an ID - the unique Ruby ID of the code-block itself is always used, so nothing besides that chunk of code could possibly respond. Much the same thing can be done for drop-lists and text-editors.

It's also far more like Ruby, and less like C!

Neat!

I've now taken the idea in my previous post, for opening dialogs using a block to set the 'finish' action, and extended it into a module which you can drop into any schematic to add a bunch of new dialog features to all of the RubyEdits in the schematic (and only that schematic!). The usual dialog calls shown in the User Guide can still be used, and they can be mixed freely with the new features, even within the same RubyEdit instance. The following features are added...

- Access to color-picker dialogs from any RubyEdit in the schematic. The start color and alpha can be set for the dialog when it is created.

- Access to file load and save dialogs from any RubyEdit in the schematic. The default folder, filename, and extension, the dialog title, and a set of file filters can be set when creating the dialog.

- All of the usual "in-place" Ruby dialogs (messageBox, edit, and dropList), plus the new ones, can be called with a code block to determine the 'finish' action. No IDs or 'Finished' methods are required in this case, and every call site can define a completely unique finishing action, which is guaranteed to be what executes when the dialog is finished.

- A little extension is added to Ruby Hashes so that they can be used as "dialog presets". Any Hash with the right key/value pairs can define both the attributes of a dialog when it opens, and what it should do when it finishes.

- DropList "dialog preset" Hashes are enhanced further, allowing each item in the drop-list to have its own unique finishing action, and for other "dropList presets" to be nested as fly-out sub-menus to any nesting depth (they also correct the annoying FlowStone bug where adding a sub-menu with the "<<"..">>" notation in the items list messes up the labels returned when the dropList finishes.)

- The same extension used for the "preset dialog" Hashes can easily be incorporated into your own custom classes so that you can build your own custom "dialog objects".

The schematic includes the module itself, which is safe to be placed in the Toolbox (no new features are defined until you drop it into a schematic), and some test modules which provide a code example for each of the new features and copious comments about how to use them.

wooo .... new toys for the toolbox !

Just having a fast check of these ... but did find a small issue with the:

Test createDropList module.

It seems I can't select the 2nd menu option [Normal, Block, Custom]. Item 1 & 3 work ... not 2

However ... ALL are working in HASH mode.

That's all I got to test up till now.

Thanks TROG !

RJHollins wrote:It seems I can't select the 2nd menu option

Good! That means it's working properly!
When you create a dropList from Ruby, there's an option to disable an item - the chosen item can't be selected, and its label is "greyed out" (though maybe not obviously enough!) I disabled an item in each of the dropLists so that I could make sure that the option for this was working properly (though I should maybe have labelled them all "Unavailable", like I did the Hash one! )

Phew - I was a bit worried for a moment there!

PS: A couple of weird geeky things I noticed while building the above.

- When you provide an ID for an in-place dialog using the usual method calls, the ID must be an integer (a Fixnum, strictly.) This isn't explicitly pointed out in the User Guide, nor will the dialog 'creator' methods complain if you pass anything else. But the IDs which the 'finished' methods receive back are always Fixnum integers (zero if what you gave doesn't naturally convert to Fixnum).

- Rather bizarrely, the stock 'messageBox' method isn't defined in the RubyEdit class. It's defined in Kernel, which is a bunch of methods inherited by pretty much every single Ruby object. So even 'nil' has a 'messageBox' method - though I'm not quite sure what FlowStone would expect 'nil' to do with the 'finished' callback!

What a wonderful collection of tools.
Thank you all for posting these and have a nice week.

Best Regards
Phil

Spogg wrote:This is a great idea!

When I was learning a bit about Ruby I set myself little exercises to make some basic functional modules. So I’ve attached these as my rather sad and weak contribution.

The quality of the coding and the style varies considerably as I made progress.

It might be useful to get comments about how stuff could be done better, or issues that I didn’t spot at the time.

Cheers

Spogg

I'm going to try to get the hang of this program.

I recently made a ruby analyzer, an EQ gain plot (no gradients) and some other very useful ruby functions that include a variant on a transfer function. I was also able to make a replacement for bells on an eq. I noticed you can only pick one of them at a time, a bummer; but maybe the codes can be merged.

I'll salvage those soon from old code.