8 replies to this topic

[Lewis Mccabe]

Hello All,

We have a couple of very large functions with multiple paging screens as child cycles of a one time screen cycle. That cycle is in turn a child cycle of the main, one time screen cycle. Execution of each paging screen is via field jumps. We have two strange issues which no one has an answer to. First - our paging line number does not display. Secondly - when adding, the line to be added is not shown, but we can successfully execute the window assigned to the first field. Anyone ever see either of these?

We started removing cycles to determine when the function would work correctly. We removed all cycles except the main and the paging within main. Line numbers mysteriously appeared. We did not test for the add problem at this point. Next I only removed the first paging screen and the paging lines appeared. It seems the two paging cycles in the parent cycle do not play well together. We have done this many times before without a hitch.

Lew

Edited by Lewis Mccabe, 14 April 2011 - 04:47 AM.

[Chris Mackenzie]

Hello All,

We have a couple of very large functions with multiple paging screens as child cycles of a one time screen cycle. That cycle is in turn a child cycle of the main, one time screen cycle. Execution of each paging screen is via field jumps. We have two strange issues which no one has an answer to. First - our paging line number does not display. Secondly - when adding, the line to be added is not shown, but we can successfully execute the window assigned to the first field. Anyone ever see either of these?

We started removing cycles to determine when the function would work correctly. We removed all cycles except the main and the paging within main. Line numbers mysteriously appeared. We did not test for the add problem at this point. Next I only removed the first paging screen and the paging lines appeared. It seems the two paging cycles in the parent cycle do not play well together. We have done this many times before without a hitch.

Lew

there are any number of things that could cause this sort of problem - without at least seeing the source code, and probably being able to run it, it will be very hard to see what's wrong. Can you post the function? (plus p4 version and platform, are any filedefs autoseq etc).

[Lewis Mccabe]

Hi Chris,

We were hoping someone had seen it before. To post, we would have to strip it down. It is 40 cycles with 50 global calls and SQL Server as the back end. Step one is we are going to do PROIV's recomendation: export entire system and reimport over the next release. Currently we are on 6.2.47 on Windows. If that doesn't solve it, I will post a stripped down version.

Thanks. Lew

[DARREN]

It may be time to refactor the code in this function Lewis. A technique we have used in the past is to break the function up into smaller functions that come together as a whole. The attached screen shot demonstrates this as all the 'header' section is a standalone function. The blue navigation bar is also defined as a separate function. Each of the sub-screens are then called based on the sub-tab that is selected. In the scenario where the sub-tab (or paging screen in your case) is, or may be known at the time of entry into header function, then the process flow can branch to the desired function.

Another scenario is where you may have several different paging/selection cycles that display the same column data, but the driving file to the cycle differs and/or the selection criteria differs. In former case we have adopted a design method where we load a 'generic' memory file and drive the paging screens from that. In the latter case the same technique can be adopted or if the tables are stored in an RDBMS then full function SQL can be used to select the desired rows. The added advantage to this implementation is that you can amend or even swap-out sections of functionality without having to release the enter process. Functions also load faster as the object code is smaller - why load a function that has 20 cycles if for the majority of the time only 2 are ever actually used.

Attached Thumbnails

• 

[Lewis Mccabe]

Hi Darren,

This is our order entry function. Orders are taken with customers on the phone in a high speed environment. Our header is already a standalone function. Our paging screens are designed just as you discuss where we have a single file keyed differently for different options. We have used global calls where we can. Most cycles do get used and used often. It is the speed of execution which is setting us apart from our competition - along with user not having to drill down to see all related data. Refactoring any further is not an option. This is one of the functions we demo'd at the EUG a few years ago which worked fine for years. Now we are adding code for lot control. The offending paging cycle is actually not new and that is what is perplexing. Thanks.

Lew

[DARREN]

It may be advantageous to post a few screen shots so that we may better understand the structure of screen and offer some suggestions. Another feature that we have used is the single click list box (where we have switched out a display only paging screen for a list box grid). As the single click can now be trapped, additional info can be displayed else where on the screen. This does not have to be limited to refreshing edit boxes, but can also be used to refresh a sub-list-box for the row that is selected (see attached)

Attached Thumbnails

• 

[Steve Houghton]

Lewis

These are very stylish screens indeed - please post some more images.

Regards
Steve

[DARREN]

Steve

These screen shots are taken from the Tower Hill Insurance application. More screen shots can be found at http://forum.proiv.c...s/list/218.page
The screen shots are of the application running through the Open Client. We are very pleased with the results, but having seen the Northgate ResourceLink product (HRS) running in Aurora I can say with authority that that is even more impressive.

Regards

Darren

[Lewis Mccabe]

Solution to this long forgotten problem: It turns out there is a limit to the number of paging fields permitted in a function. It has been a while so I am not sure the exact number. This problem was in our function in version 6. The paging field limit has been drastically increased in version 7. When we moved our code up to version 7, problem solved.