INPUT Box [now to use RUBY]

[RJHollins]

some consolidating.

Have also dropped in a module that restricts number input 0 - 127 [for MIDI data]. Right now this is 'green' ... should be converted to RUBY. [reading up on that].

I've started some 'Properties' values. There are some spurious property values at the top. I've not found where they are coming from. Need to be identified and/or removed. [this is what happens, I suppose, when modifying rather than fresh rewrite].

Anyway ... hope the 'Experts' can take a peek and help me clean up

Here's the latest.

[Nubeat7]

To note: The disk data is not subject to the LEN mod. Normally the disk data would come from previous entry [and limits] from the edit box ... so this should not be an issue.

hmm yes that should be feed into the restrictions part too, then you will always get valid data also when a wrong file is loaded... for example some wierd text into the 0..127 would be 0

i followed your version and cleaned up a little bit in the restrictions there is the 0..127 part now , in this case the length is not needed so i deleted it if you need it in another editbox just change the restrictions module

i think the best way is to keep the basic editbox just with some design properties like it is now and just change the restrictions code because like said before it is always very specific and like you see in the case of 0..127 length is not needed so why to put it in? better you just change the restrictions code for every case and the code stays small and tight, anyway its just one part which have to be changed for every case, and it would be a big mess to put every possible case into one code

[RJHollins]

Thank-you NuBeat ... not only for this new example you've posted [which I must study] ... but just as important, to read on the design philosophy you present. I think that that is as important as the code !

Learning how to solve 'smaller' problems, rather than trying to 'take on the whole universe' is a very easy trap I've falling into. Equally ... seeing how an experienced programmer codes a solution to something I've toiled over can be a powerful learning experience.

I'll look at your latest posting after some rest. Thank-you!

[RJHollins]

OK ...

Thanks to NuBeat, we have a much better 'Edit Box' !

With something so fundamental as this, I want to do plenty of testing [before replacing the 50+ boxes in my project].

So far looking really good.

There are a couple functional things that I will adjust, for example, setting the font & text size from a common 'properties' to feed both modules.
2. still trying to track down where those 'extra' property values are, and get those removed

The 'Restriction' module is a great idea. That'll be the place to hold all the possibilities. Wire up as needed.

The 0 - 127 Ruby code. I need this for some special MIDI data.
I've made a modification to the code. If the User enters data > 127, the output goes to 0
----------------------
if s > 127
s=0
end
---------------------

For my project, 0 is an INIT patch, and it's the only 'safe' value I can use. So this works fine !

ok ... back to testing!!!

[Nubeat7]

There are a couple functional things that I will adjust, for example, setting the font & text size from a common 'properties' to feed both modules.
2. still trying to track down where those 'extra' property values are, and get those removed

yes to choose font in the properties is a good idea just use the font prim for that iinside the propertiesmodule.. also the colors for the editcontrol could be made for properties... btw this extra stuff in the properties is gone since the last version! maybe it was an artefact from the old schematic where i took it out to modify it....

for the restrictions and string manipulations maybe we could enlarge the small list i`ve posted before (the one with the string number float examples ) to have some growing references for the restrictions , where we just need to copy paste from, could also be very useful in some other situations, always good to have stuff like this in the toolbox

[RJHollins]

Hi NuBeat !

I've just started testing the new edit box within my app.

First ... the 'editing' is so much better !

As to the 'Restrictions' section. Your idea is great ! These will be nice additions for the toolbox

Some ideas ... questions ...

Here's a situation that presents itself.

If we set an Edit/Display box to a specific String Length. I've noticed that text 'characters' have different widths

A 'box' that can handle '123456' might be fine ... but now enter 6 'W's 'WWWWWW'. Now we have a problem.

I mean, this could get crazy. For certain entries the display would be fine, yet for other values, things would be clipped [although the value is still in place].

Designing an 'Input Box' for the possible largest font width would really chew up screen real estate. And certain values would be so narrow that they look like they're floating in a ocean

Curious if there could be a solution that could vary the font size down [from a designed MAX] ... if that makes sense. Don't even know if this is possible ... just thinking out loud

back to testing for me....

[RJHollins]

hmmm ... we have a problem Houston

OK ... editing data within the box is working. BUT

The Input to the front end of the Edit Box ... for Data coming in from Disk is not !

The 'internal' value is not being replaced with the Disk data [coming in from an Array].

I'll post up a schematic ASAP.

note: pushing a value into the front end will change the Edit Box display ... but the edit box is not outputing
that value.

I'm wondering if this is why TROG had some coding going on outside the EDIT BOX [as I have shown in the 1st message pix in this thread] ... off to test.

[Nubeat7]

If we set an Edit/Display box to a specific String Length. I've noticed that text 'characters' have different widths

A 'box' that can handle '123456' might be fine ... but now enter 6 'W's 'WWWWWW'. Now we have a problem.

just use a monospaced font then or let the box big enough ..
here is a list of monospaced fonts http://hivelogic.com/articles/top-10-programming-fonts

[Nubeat7]

hmmm ... we have a problem Houston

OK ... editing data within the box is working. BUT

The Input to the front end of the Edit Box ... for Data coming in from Disk is not !

The 'internal' value is not being replaced with the Disk data [coming in from an Array].

I'll post up a schematic ASAP.

note: pushing a value into the front end will change the Edit Box display ... but the edit box is not outputing
that value.

I'm wondering if this is why TROG had some coding going on outside the EDIT BOX [as I have shown in the 1st message pix in this thread] ... off to test.

oh, yes, because there is the sample and hold prim in between there must be sent a trigger when extern data comes in, just connect the extern input also with the done trigger!

[RJHollins]

If I could follow your instructions ... I would certainly try to do that

But I have MUSH for Brains



OK ... did I understand correctly ?

capture2.jpg (58.29 KiB) Viewed 16901 times

Thanks