Threaded Mode | Linear Mode

tcab · 11-04-2018, 05:28 AM

I've just noticed a nice feature with the HP42S/Free42's INPUT command. If you put some text in the alpha register then do an AVIEW prior to an INPUT, you get the alpha message on the top line of the HP42S display and the input prompt on the second line of the display - nice.

00 LBL "ABC"
01 "VV will appear"
02 ├" below"
03 AVIEW
04 INPUT "VV"
05 RTN

However there seems to be a pitfall. If the alpha message takes up two lines, then you won't see the subsequent prompt generated by INPUT. This is because the input prompting area on the second (bottom-most) line of the HP42S display is occupied by the multiline alpha string and the INPUT command doesn't seem to clear it. So you never see the prompt, unless you hit backspace.

00 LBL "ABC"
01 "VV will appear"
02 ├" below"
03 ├" good luck" <--- extra line making the display wrap onto second line
04 AVIEW
05 INPUT "VV"
06 RTN

Has anybody noticed this before? Is this a quirk, bug or feature to be taken advantage of? I've only tested on Free42 - does the real HP42S behave the same?

Thomas Okken · 11-04-2018, 07:13 AM

I just checked this behavior in Emu42, and it looks like Free42 handles this incorrectly. In Emu42, the message is cleared before the INPUT prompt is shown, so the INPUT prompt shares the display only with X or the menu, never with a message.

**rprosperi** · 11-04-2018, 02:00 PM

(11-04-2018 05:28 AM)tcab Wrote: Is this a quirk, bug or feature to be taken advantage of? I've only tested on Free42 - does the real HP42S behave the same?

The described behavior does not occur on a real 42S; in the first case, the display shows the Y register contents in the top line and the "VV?" prompt in the lower line.

In the 2nd program program, the behavior is the same as the first.

It seems this 'error' in Free42 could be more desirable than genuine 42S behavior, under the right conditions.

Thomas Okken · 11-04-2018, 09:23 PM

(11-04-2018 02:00 PM)rprosperi Wrote: It seems this 'error' in Free42 could be more desirable than genuine 42S behavior, under the right conditions.

The right conditions being: one-line message being displayed, but not a two-line; and no menu active...

I haven't looked at the actual code yet, but it appears that it's simply missing the equivalent of a CLD at the beginning of the INPUT logic.

I'll fix this in the next release, but I don't know yet when that will be. I'd like to redo the iOS UI first, and this INPUT bug doesn't seem very serious.

burkhard · 11-05-2018, 02:00 AM

(11-04-2018 09:23 PM)Thomas Okken Wrote: I'll fix this in the next release, but I don't know yet when that will be. I'd like to redo the iOS UI first, and this INPUT bug doesn't seem very serious.

“Redoing” the iOS user interface sounds like a big deal.
What are you scheming or what needs redoing?
It looks great to now me :-)

Thomas Klemm · 11-05-2018, 06:16 AM

(11-05-2018 02:00 AM)burkhard Wrote: What are you scheming or what needs redoing?

(04-21-2018 10:51 AM)Thomas Okken Wrote: iPhone X support https://developer.apple.com/ios/update-a...-iphone-x/

Thomas Okken · 11-05-2018, 10:23 AM

(11-05-2018 06:16 AM)Thomas Klemm Wrote:
(11-05-2018 02:00 AM)burkhard Wrote: What are you scheming or what needs redoing?

(04-21-2018 10:51 AM)Thomas Okken Wrote: iPhone X support https://developer.apple.com/ios/update-a...-iphone-x/

Yes, and to elaborate a bit: iPhone X support is now a hard requirement, meaning, you can't even upload an app update any more if iPhone X support is missing.

In theory, this shouldn't be a big deal. You should be able to achieve basic iPhone X support simply by adding a launch image of the appropriate size. However, when I did that, the app no longer used the whole screen on devices with 4" screens (5, 5c, 5s, SE). Very frustrating.

The probable cause of this problem is that the way the Free42 iOS user interface is structured is just wrong. It doesn't match anything you'll see in any code examples. This causes certain quirks, like certain UI elements not being positioned quite right, and the lack of transitions when switching between views. So far, the issues have been minor and strictly cosmetic, but now I really have to deal with this... by finding out how an iOS UI is really supposed to be built and doing it right this time.

It shouldn't be a lot of work, since it's only about creating and positioning views. There's nothing wrong with what happens inside those views, so most of the UI logic will stay as it is. But still, a significant pain in the backside.

tcab · 11-05-2018, 11:18 AM

If, in the course of this GUI re-working of Free42, there is a way of having Free42 on iPad have the virtual printer tape on screen, side by side with the Free42 calculator (e.g. in landscape mode) - that would be a dream come true.

However if this request makes things at all difficult - please forget I suggested it :-) I remember trying to figure out Xcode and its UI builder once - and it did my head in. Good luck.

Thomas Okken · 11-05-2018, 11:29 AM

(11-05-2018 11:18 AM)tcab Wrote: If, in the course of this GUI re-working of Free42, there is a way of having Free42 on iPad have the virtual printer tape on screen, side by side with the Free42 calculator (e.g. in landscape mode) - that would be a dream come true.

However if this request makes things at all difficult - please forget I suggested it :-)

That isn't on my to-do list right now. However, a properly structured UI would make implementing such a side-by-side mode pretty easy (at least in theory!) so I wouldn't rule out doing it at some later date.

(11-05-2018 11:18 AM)tcab Wrote: I remember trying to figure out Xcode and its UI builder once - and it did my head in. Good luck.

Aye, iOS UI development is no fun. It's by far my least favorite platform, in that regard.