PH to Axiant migration

shulbert@littlejohnfrazer.com shulbert@littlejohnfrazer.com
Tue, 30 Jul 2002 9:27:35 +0100


audrey,
technically, the biggest gotcha comes from the fact that text powerhouse is serially processed and axiant pretends to be a gui "parallel" environment. the result of which is that ID SAME doesn't work by default the same way under 3.1 thin client as it does in text powerhouse (i'd be grateful for some feedback on other developers' experience of this). you'll have to deal with this at some point, and better in the initial migration than after the first phase of testing.

in thin client, axiant is acting as a front end for quick in the background. when the user clicks on a field, axiant generates what it thinks the command sequence should be for quick to activate the field. unfortunately it doesn't take any notice of which fields are or aren't active at the time. e.g. clicking on the third field in an id same group will always generate "n;;" (group id, next, next) even if two of the fields are inactive.

there seem to be three specific instances where this is an issue for us, two of which cognos have come through with workarounds for, the third i'm still waiting on.

1. long descriptions
throughout our text app we have code like this:

<PH>
field code_item
field code_desc id same display
</PH>

where code_desc is retrieved from a lookup table.
if the user clicks on the second field axiant generates the command sequence "n;".
since there is only one field active the next command is treated as a "next data": this gets a new page of data, clears the data fields if there isn't one, or generates a "Data has been changed but not updated" warning, none of which are exactly helpful to the user.
three (at least) choices:
a. change all the fields marked "id same display" to "noid display" (you can use your favourite batch text program to do this before the migration);
b. change the left click event on the second field to "Current Field ID";
c. warn the users not to click on fields they know they shouldn't.

2. lookup screens/cluster events
a fairly standard algorithm is to present the user with a selection of records and then run a subscreen or return a value based on which record the user picks. we have done this using clusters and numbered designers:

<PH>
cluster occurs with detailfile

field element1
field element2 id same
field element3 id same

cluster

...

<choice1>
procedure designer n ; cluster id
begin
  run screen screen2 passing element1
  end
</choice1>

<choice2>
procedure designer n ; cluster id
begin
  let tvalue = element1
  return
  end
</choice2>
</PH>

choice1 is for screens displaying detail, choice2 for code lookup screens returning a value.

clicking on element3 will generate the command "n;;". since there are no fields to prompt for you get two "next data" commands. these are carried over to the called/calling screen, generating much confusion among users.

cognos' preferred solution is to change the left click event for all the fields in the cluster to "Current Field ID".

3. custom field orders
in powerhouse, a complex custom field order is set up using id same and a numbered designer procedure.

</PH>
field element1
field element2 id same
field element3 id same

...

procedure designer n ; element1 id
begin
  if not changemode
  then accept element1
  accept element2
  if boolean1
  then accept element3
  end
</PH>

axiant doesn't deal with this at all.
i've been trying to get a response on this from cognos over this for nearly a year now with no luck.
i did, however, discover a workaround:

1. change all the fields to id default.
2. create separate designer procedures for each field

</PH>
field element1
field element2
field element3

...

procedure designer m ; element1 id
begin
  if not changemode
  then accept element1
  end

; element 2 doesn't need it's own procedure since it's not conditional

procedure designer n ; element3 id
begin
  if boolean1
  then accept element3
  end
</PH>

if you really must have fields prompted for in the same order you can keep id same/procedure designer n and change the left click event of the id same fields to be "Current Field ID": this will go through all the processing all the time, which isn't very windows-like.
if you have deeply nested ifs the individual numbered designers can get very complicated. if there are a lot of fields this can become a bit of a nightmare to maintain.

if you need more pointers, please feel free to contact me on or off-list.
regards,
stephen.



 -----Original Message-----
From: 	audrey.yates@cdhb.govt.nz [mailto:audrey.yates@cdhb.govt.nz] Sent:	Monday, July 29, 2002 5:03 AM
To:	powerh-l@lists.swau.edu
Subject:	PH to Axiant migration

Hello all.

We are about to embark on this migration with trepidation. What 'traps for young players' are there that we should be aware of? Any tips and tricks you can tell us about?

Thanks in advance for your help

Audrey
Analyst/Programmer
Canterbury District Health Board
Christchurch, New Zealand



**********************************************************************
** This email and attachments have been scanned for content and viruses and is believed to be clean **

This email or attachments may contain confidential or legally privileged information intended for the sole use of the addressee(s). Any use, redistribution, disclosure, or reproduction of this message, except as intended, is prohibited. If you received this email in error, please notify the sender and remove all copies of the message, including any attachments. Any views or opinions expressed in this email (unless otherwise stated) may not represent those of Canterbury District Health Board
**********************************************************************


= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.swau.edu
Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
Unsubscribe: "unsubscribe" in message body to powerh-l-request@lists.swau.edu
http://lists.swau.edu/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.




The information contained in this communication is confidential and may
be legally privileged. It is intended solely for the use of the
individual or entity to whom it is addressed and others authorised to
receive it.  If you are not the intended recipient you are hereby
notified that any disclosure, copying, distribution or taking of any
action in reliance on the contents of this information is strictly
prohibited and may be unlawful.

Littlejohn Frazer reserves the right to monitor the content of any
message sent to or from littlejohnfrazer.com and its associate domains,
fmi-litjon.co.uk and litjon.co.uk

A list of partners may be inspected at 1 Park Place, Canary Wharf,
London, E14 4HJ

Registered to carry on audit work by the Institute of Chartered
Accountants in England & Wales, and authorised by the Financial
Services Authority to provide financial services