Why is INPUT such a Rube Goldberg?

[acmeanvil]

Before I start I just want to say I love the Prime, mostly for the inclusion of PPL and a IDE that runs on ye olde pc (because, let be honest, a calculator keyboard, no matter how good, still sucks compared to a real one...). I am (was) an avid user of UserRPL and thought that was pretty good until now.

However I have one really big grump with PPL; why is the new INPUT() so convoluted? The syntax to have a input box with one field, one drop down, and a couple check boxes is pretty wild. Why can't couldn't the input setup be broken into parts something like:

INPUT_GROUP, a meta function which purely for layout and display of individual input sub functions.

Then the sub functions:
plain INPUT (like the original with only a title,input fields, and info about the inputs fields.
DROPDOWN, a drop down menu function, syntax similar to plain input.
CHKBOX, check box function, ditto...
etc. insert your choice here....

So you could create:
INPUT_GROUP({INPUT(A,"title","input","description")},{CHKBOX({B,1},{C,1},"label 1","label 2"})
for an input page with an input field and a set of check box.

Additionally, why not extend INPUT_GROUP to a function that could do something like the following where the initial input would be a set of checkboxs which would drive what drop down menu was presented next all with in the same INPUT_GROUP window.
INPUT_GROUP({INPUT({CHKBOX({A,1},{B,1},"label 1","label 2"}
IF A==1 and B==0 then {DROPDOWN(C,"choice1","choice 2"},
IF A==0 and B==1 then {DROPDOWN(D,"choice3","choice 4"}
ELSE {DROPDOWN(E,"choice 5","choice 6"});

Just a thought.

[Han]

The simple form is: INPUT(var)

The intermediate form is: INPUT(var, title, label, help, reset, initial)

The advanced form is the same as the intermediate, except var, label, reset, and initial are actually lists of that respective type:

Code:

INPUT(
  { var1, var2, …, varn },
  title,
  { label1, label2, …, labeln },
  { help1, help2, …, helpn },
  { reset1, reset2, …, resetn },
  { initial1, initial2, …, initialn }
)

The only other change is that var1 through varn have the form:

{ varname, type_specifier, position }

[Tim Wessman]

(12-17-2014 01:45 AM)acmeanvil Wrote:  However I have one really big grump with PPL; why is the new INPUT() so convoluted?

Basically, because it lets you do so much...

If you take a look at the INFORM on the 48 series, you'll find the same level of convolution-ness once you get past the basic things. When you are trying to allow the user to create full screen UI elements, it gets hairy really quickly. The other issue with the suggestion you've put forward is that "how does the system treat something like CHKBOX()?". Is that a function? If so, what does it do by itself when not contained in a INPUT command? If it just becomes a "Tag" for identification purposes, then it would require a whole new creation of an object type, handling code everywhere, etc in order to seamlessly work or not work as appropriate.

Now I think your suggestion is good and we did look at or consider doing something like that. For various technical and implementation reasons though it would not have worked out as good as I think you imagine.

What is really needed is a INPUT builder tool, and that is something we can do! :-)

[Tim Wessman]

(12-17-2014 02:32 AM)Han Wrote:  

Code:

INPUT(
  { var1, var2, …, varn },
  title,

I think you can also have { "title1", "title2"...} so each page gets its own. I may b remembering wrong there though.

[acmeanvil]

Hi Han,
Thank you for your reply. I didn't articulate myself as well as I should have. I was trying to give pseduo-code examples, which on a second reading leave a bit to be desired.

My larger question was whether making INPUT more of an object oriented-like function was possible/feasible.

Currently, more complex uses of INPUT such as the following (Thanks Giancarlo) will get the job done, but are arguably tough to read and debug, particularly for the novice (ie the student who this Prime is in theory aimed at).
INPUT({{A,[2],{15,35,1}},{B,2,{15,5,2}},{C,2,{55,15,2}},{D,{"uno","due","tre","12345678901234567801234567890123"},{20,70,3}}}, "Main title",{"Name", "Male","Female","children"},{"string A","flag B","flag C","How many children"},{"",0,0,0},{"",0,0,0})

Where as the use of discrete objects such as (very bad psuedo code to follow) maybe useful:
INPUT_GROUP((INPUT(A,"title","input","description")),(CHKBOX({B,1},{C,1},"label 1","label 2"}));

Which could also be rewritten:
I1:=INPUT(A,"title","input","description");
I2:=CHKBOX({B,1},{C,1},"label 1","label 2"});
INPUT_GROUP(I1,I2);

allowing for easier interface building and greater clarity in the final code. Keeping in mind that elements such as variable type, object position, object color, etc. are not included above for clarity, but would be in the actual implementation.

As before, it is simply food for thought.

[acmeanvil]

Thanks for the reply Tim,
I think you beat my reply to Han in.
Yes, INPUT builder does sound great!

Don't get me wrong, there is nothing more rewarding than actually getting all the braces in the correct place and having it run perfectly. I do like having the ability to make INPUT do exactly what I would like in a single statement, even though it has a habit of frustrating me.

From the looks of it you guys have spent plenty of time going over what is possible/useful/necessary when putting PPL together, with the result being a very good tool IMHO.

To your question about what overlap, (it's mostly ideal speculation, but fun though...) I would envision the current INPUT would be broken into its parts, so INPUT (for lack of a better name..) would become a function(container?) for creation of input boxes only, CHKBOX for check boxes, DROPDOWN for drop down boxes, etc. INPUT_GROUP() would be roughly analogous to the current INPUT(), in the sense that it uses the separate elements above to create an input page. However it would be more of a canvas on to which the elements could be positioned. Screen position, background color,etc for each element would be part of the INPUT_GROUP syntax. So your input box would be: define the elements->place in an input group->run the group.

Also, something like a CONDITIONAL_DROPDOWN with content based on the output a previous set of check boxes on the same page would great.......

Anyway, still all ideal speculation though.

[Giancarlo]

Hello,
The beauty of this command are the different shapes of complexity of it depending on your needs. You can start with a INPUT (A) and then create a multipage form with multiple interelated (or not) checkboxes, drop down lists and so on.

I think that HP made a real effort on this side trying to satisfy both newbees and experienced users. Thanks for that HP.

Do not take my INPUT arguments too seriously. It was just a test to show the power of this command with positions, argument types, checkboxes and so on.

I think that a builder would be nice but my development process usually iterate writing the code and at the same time trimming the gui. It is something easy to me while i think about the algorithm which is always more difficult for me ( and sometimes not possible for me).

Please also consider that some users would also like to display some grobs on the same screen to display for example what the variables are. I am one of these :+)

Thanks

Giancarlo

[cyrille de brébisson]

Hello,


INPUT is a beast...
and you should see the internal version of it, it is even worse! but ho so powerful...

sadly enough, with myriad of possibilities comes myriad of configurations options, making the full use of it relatively hard...

But, has pointed out, the basic version: INPUT(A) is designed to be VERY user friendly :-)

As for OO, well, PPL is not yet there, unfortunately, so it will have to wait.
Also, INPUT (or more exactly Cdialog, the underlying control) is not parametrized internally by an object but by a series of structures and call backs. Even if they could be replicated as objects does not have a 1:1 mapping, so any solution would be clumsy...

Cyrille

[acmeanvil]

Hello Cyrille and Tim,
This may not be possible, but is there any documentation you could share showing at a relatively high level, what is going on below the surface of the OS? It is more a curiosity, though it always seems to help when you can have a glimpse behind the curtain.
Nate

[cyrille de brébisson]

Documenta.... What?

There is a lot there, but if you look at the whole graphing system, it's a fairly simple (and obvious) set of Cwindow derivatives, all representing 1 control and being 'graphical' childs of each others...

Cdialog represents an INPUT box/form and receives a structure that tells it how many editos, labels... are on each pages, what they are and allows to control them.

The INPUT parameters is a static form of that.

Cyrille

[acmeanvil]

so it does run windows CE....

[Tim Wessman]

(12-19-2014 09:22 PM)acmeanvil Wrote:  so it does run windows CE....

Nope. I assume because the Cwindow comment. Only so many ways you can name a Class that does Windows...

Cdialog, CEQList, CChoose, etc.

[Snorre]

I've thought that Cwindow was the Window class made by Cyrille, initially written as abstract Twindow by Tim, then generalized as Bwindow by Bernard, extended as Mwindow by Matt, and finally exported as Jynput by Jean-Yves, but renamed by some HP-marketing people (who thought that would be easier) to Input.

[acmeanvil]

Well, the good news then is that all my dreams of a Linux powered rpn unicorn calculator....that someday will support python....aren't shattered, yet.

[bobkrohn]

Here's an idea.
Could there be built a graphical PC Program for the sole purpose of generating the line of code to create "complex" Input screens??

Kind of a MS VisualBasic graphical type thing.

That's all it would do. Assist in creating that one line. Then Copy/Paste into the ConnKit window showing your program.

[mstram]

(12-17-2014 03:04 PM)acmeanvil Wrote:  INPUT({{A,[2],{15,35,1}},{B,2,{15,5,2}},{C,2,{55,15,2}},{D,{"uno","due","tre","12345678901234567801234567890123"},{20,70,3}}}, "Main title",{"Name", "Male","Female","children"},{"string A","flag B","flag C","How many children"},{"",0,0,0},{"",0,0,0})

Pasting that line into the Prime Emulator (version 2013 11 25 Rev.5447) gives a syntax error.

Does it work in the real calculator ?

[Dougggg]

(12-21-2014 06:10 PM)mstram Wrote:  

(12-17-2014 03:04 PM)acmeanvil Wrote:  INPUT({{A,[2],{15,35,1}},{B,2,{15,5,2}},{C,2,{55,15,2}},{D,{"uno","due","tre","12345678901234567801234567890123"},{20,70,3}}}, "Main title",{"Name", "Male","Female","children"},{"string A","flag B","flag C","How many children"},{"",0,0,0},{"",0,0,0})

Pasting that line into the Prime Emulator (version 2013 11 25 Rev.5447) gives a syntax error.

Does it work in the real calculator ?

It should work with the latest firmware