HP Forums

Full Version: Modeless dialog box problem while invoking Function app from the code
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I attempted to write an application which would optimize the function, and then display it on the screen using built-in Function app.
It worked functionally, but I ran into UI problems I could not work around.
Here is a simple application illustrating the problem:
Code:

#pragma mode( separator(.,;) integer(h64) )

EXPORT GAS()
BEGIN
  Function.F0:='3.79/(1.605*X)*100';
  Function.Xmin:=0;
  Function.Xmax:=50;
  Function.Ymin:=0;
  Function.Ymax:=25;
  Function.CHECK(0);
  Function.UNCHECK(1);
  Function.UNCHECK(2);
  Function.UNCHECK(3);
  Function.UNCHECK(4);
  Function.UNCHECK(5);
  Function.UNCHECK(6);
  Function.UNCHECK(7);
  Function.UNCHECK(8);
  Function.UNCHECK(9); 
  STARTAPP("Function");
  STARTVIEW(1,1);
  RETURN("X - mpg, Y - l/100km, Press OK or Enter to continue...");
END;
The application exports a function converting gas mileage from mpg to l/100km (somehow this problem came to mind to be used as an example...). No fanciness, just bare-bones. Even slot unchecking is done sequentially, not in a loop.
After the program is finished, it displays the dialog box. This dialog box can be used for displaying additional info, like in the example. The problem is with the behavior of the screen after the dialog box is displayed.
This dialog box is *not* a modal one, like one could expect. If you start making sweeping gestures on the screen when it's displayed, the screen moves, and its contents get badly distorted. When the dialog box is closed (either by pressing soft Okay of hard Enter), the screen remains damaged, and to fix it you have to move it such that the distorted area is shifted out of the display area.
Technically a small thing, but very annoying.
Does anybody know of a better way to deal with a problem of invoking Function app from the code?

Darius
Interesting, same thing happens with MSGBOX (if used instead of RETURN). I expected both cases to disable the touchscreen above the menu area.

Actually the CHOOSE command behaves similarly as well, in that case I expected the touchscreen only inside the choose box and within menu area to respond.
I am suspecting this is happening because all dialog box-like objects objects in the Prime code must be derived from the same type of object which happens to be modal; inheritance takes care of replicating this unwanted issue to child objects.
(I am drawing this conclusion based on the snippet of the code posted once by Cyrille--it looked like C++ to me.)

Darius
Reference URL's