DSP Robotics Support

Drnkhobo wrote:Keep it up man, you picked up Ruby FASTER than I did

Ah, well I have been lucky to have some good teachers. I use the SketchUp 3D software at work, which has had its own Ruby API for many years. So although I am quite a 'newbie' still, I have learned so many things already from the 'gurus' over on their forums - and I work in an office full of guys who are top-class coders in dozens of languages.
So I have a bit of an unfair advantage!

Hi All,
A fix for the "out of range" bug now uploaded to the top post.
A very silly error, I was trying to use '!' to invert the range test '!(0...@rows)===selection). But '1(0...@rows)' rakes precendence over the '===selection' part, so the return value was always the same. I refactored it using 'unless' instead of 'if', which actually makes the code a bit more tidy anyway.
Thanks for the accurate bug reports - it makes fixing this kind of thing so much easier!

Seems neat!
I wonder if a preference array would be better than all those inputs...

infuzion wrote:I wonder if a preference array would be better than all those inputs...

I did wonder about that - but individual inputs make the coding easier as you can refer to the inputs by name (so long as you labelled them of course!). Apart from the case statement in the events routine, you don't have to worry about using correct array indices all over the code, so it is more maintainable if you re-order or delete inputs.

Just two questions

There's a way control the appearing of the scrollbar , such like "Never,Always,Auto"?

Can I get rid of the heading?

unkargherth wrote:There's a way control the appearing of the scrollbar , such like "Never,Always,Auto"?
Can I get rid of the heading?

Those should be quite easy to add (or rather, take away!)
I made the design with every feature that I could think of to start with, as I figured that taking stuff out is easier than adding stuff in. Looks like the initial bugs have been sorted out, so I can now start on a bit more customisation.

BTW) Re: scroll wheel. I have looked into this on all the Ruby forums that I can find, and I don't think it is going to be possible unless the dev's can add those events to the built in system. Unlike cursor position or testing the keyboard, the scroll wheel does not have a 'state' that you can inspect; each click of the wheel has to send an event into the active window. In this case the active window is the FS3 editor environment itself, and there is no way to intercept these messages and re-direct them into our schematic.

trogluddite wrote: I work in an office full of guys who are top-class coders in dozens of languages.
So I have a bit of an unfair advantage!

Not fair!!!!!
Lucky bro, thats quite a resource you have at your side

Latest update (Beta 03a) now available in the top post of the thread.

New features (thanks to all for the suggestions)
- Headings can now be hidden
- Scroll bar now has Show always, Never show and Auto-hide modes.
- An integer output to show how many lines of text will fit into the box.

NB) Even if you choose to hide the headings, you do still have to give a list of column names, as they are used inside the code for various things.

Also a few bits of the code have been improved to reduce unnecessary redraws,and improve CPU efficiency (especially for data sorting).

Wow!
This is brilliant!!

I've been trying to learn Ruby for a few days now. Just to see if it brings something useful(149$ useful) to my SM projects. I haven't gotten very far in finding things that Ruby excels at. But this, oh man.. This is exactly the kind of thing that shows off Ruby at it's best! <3

Glad you like it. Matti.
Yes, this is just the kind of thing Ruby is good at - if you ever found yourself wishing for proper multi-dimensional arrays, unordered lists, data sorting, searching and replacing, then you will like Ruby. And no more Area->Float, Float->Area when trying to make complex graphics - that always ended up so messy!