Posted 17 October 2006 - 03:15 PM
I have a question about the input scope of icons as buttons within ProIV which I'm hoping someone here may be able to help me with.
The environment in question is Windows, proiv kernel version circa 5.5, (ocx) client version 5.x.x.
I am using a screen function (function A) with a screen format that contains some icons to 'centralise' the layout of some navigation buttons / headers / menu buttons within an application. The idea is that this function A paints the top few lines, and the bottom line of a screen, and is called (one time Y, no input fields) before exiting to another screen function (function B, there would be many of these) that paints the center area of the screen with more context aware data. I have found that as long as I don't set the primary LS in function B to clear the screen, the icons from function A (which has already been exited) are still present and clickable on screen. The fnkeys specified for these icons in function A can be intercepted / tested in fnkey logic in the relevant LS in function B. This suits my purposes quite well but I am concerned that this behaviour is not by design, and may be broken / fixed in later versions of the ProIV client, resulting in fairly extensive rework. Have any of you any thoughts on / experience of this behaviour? I would also be grateful for any other suggestions / tricks people may have on how to centralise things like these navigation buttons etc., without resorting to custom ActiveX components.
Posted 17 October 2006 - 03:58 PM
We have been using the same approach for over a year without problem. In our setup each function calls a global screen(header function) in the calling function's entry logic which paints the screen with header information with anywhere from 3 to 6 icons (the icon presentation is set based on parameters passed to the global by the calling function).
As you note the calling function adopts the fnkey logic from the header function so this logic must be set in each function, and we simply solved this by dedicating some fnkeys at the end of each function.
It has worked well for us.
Posted 17 October 2006 - 04:08 PM
Forgot to mention in the approach I outlined above you do not have to worry about not clearing the screen in the calling function's LS1, because the global is called in the entry logic of the calling function. So it gets called and stays there as long as none of the formats in the calling function overwrite it.
Posted 18 October 2006 - 08:41 AM
Posted 18 October 2006 - 09:48 AM
Screen functions call a global screen which paints the tabs, help and navigation icons, and leaves a set of function key numbers which can be used by the main screen function. To identify the difference between global events and local events, we defined that function key numbers 100-131 are for the global functions, and 33-99 can be used locally. Creating one global logic which is set up for the global function keys (100-131) makes maintenance a lot easier
Posted 18 October 2006 - 10:37 AM
Posted 18 October 2006 - 01:19 PM
It saves some maintenance when you have to add additional parameters to the global update, you only have to change the global logic, and regen every function which accesses that global....
Posted 18 October 2006 - 03:41 PM
Posted 19 October 2006 - 06:23 AM
If you use native, you can define that in @GLOGIC (I in the step), or in @STUDIO (Both work on the native files)
Extra parameters that need to be passed on from the function to the global can be defined as EXTERN variables (otherwise you still will have to update all functions calling the global logic), but in our case these are ususaly restricted to fields like @FUNCT, @CURFUNCT, @FLD, etc.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users