Hi,
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.
Thanks,
Jim.
Click the link below to see the new game I'm developing!
Icon scope
Started by
Guest_Jim_*
, Oct 17 2006 03:15 PM
9 replies to this topic
#2
John Cummins
-
- Members
-
- 10 posts
Member
- Gender:Male
- Location:Ramsey , United States
Posted 17 October 2006 - 03:58 PM
Jim,
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.
John
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.
John
#3
John Cummins
-
- Members
-
- 10 posts
Member
- Gender:Male
- Location:Ramsey , United States
Posted 17 October 2006 - 04:08 PM
Jim,
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.
hth
John
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.
hth
John
#4
Guest_Jim_*
Guest_Jim_*
-
- Guests
Posted 18 October 2006 - 08:41 AM
Thanks for the response John. It's reassuring to know other people are using this approach in production without issue. One of my colleagues is also checking with ProIV support that this behaviour is by design - will post back any reponse we get - thanks.
Jim.
Jim.
#5
Wim Soutendijk
-
- Members
-
- 216 posts
ProIV Guru
- Gender:Male
- Location:Netherlands
Posted 18 October 2006 - 09:48 AM
To give you even more reassurance: we do the same thing.
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
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
#6
Guest_Jim_*
Guest_Jim_*
-
- Guests
Posted 18 October 2006 - 10:37 AM
Thanks for the response Wim. It seems like this method is going to be a runner. I was speaking to a colleague this morning regarding John's approach, using a global to do the 'decorations', and he suggested the same approach as you regarding centralising the fnkey logic also, though in a global update rather than a global logic as we need some file updates. Great minds think alike I guess 
. Thanks.
Jim.
. Thanks.Jim.
#7
Wim Soutendijk
-
- Members
-
- 216 posts
ProIV Guru
- Gender:Male
- Location:Netherlands
Posted 18 October 2006 - 01:19 PM
In fact our global logic also calls a global update for the same reason, we need to read some files.....
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....
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....
#8
Guest_Jim_*
Guest_Jim_*
-
- Guests
Posted 18 October 2006 - 03:41 PM
Thanks Wim. One question on your approach - you mention using a global logic to call a global update, thus saving time when the interface in the global update needs to have additional parameters added. How does this approach help you when you need to add additional parameters to the interface? I though the only place to specify the corresponding variables passed to the interface was within the function definition. Is there some way to dynamically define an interface in the global logic? It may be relevant that I'm using native. Thanks.
Jim.
Jim.
#9
Wim Soutendijk
-
- Members
-
- 216 posts
ProIV Guru
- Gender:Male
- Location:Netherlands
Posted 19 October 2006 - 06:23 AM
You can set up a mapping in the global logic to the global function.
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.
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
Click the link below to see the new game I'm developing!
