Weirdness in screen program (not that long!)

[Bruin, J.M. de]

Hi guys,

I want to come back to my problem with the temp fields and the promting of one
of them.
I wrote about the workaround i.e. putting the first 2 temp fields in a separate
cluster. Well, it wasn't the complete workaround. It turned out that the last
field in the second çluster'was prompted i.s.o. the last (temp) field.
Well, the fields size was that of the last field in the 'second cluster' as well
as the position, the NAME however was that of the last (temp) field and the one
prompted from within the designer.
I had to increase the field size to 6 with "Size 6" on the field itself to be
albe to enter a correct value for t'OBJECT_CODE.
In the end: things do work but not as (I) supposed it to work.

It seems to me this is a one of those bugs in PH that has to do with strange
behaviour in and around cluster I have come accross several times since I
started to use PH some odd 15 yr ago.

Any suggestion in how to solve it for real are welcome. Any requests for the
full source as well.

Regards,

Mark

-----Original Message-----
From: Peter Bateman
To: Bruin@WT.TNO.NL
Cc: powerh-l@lists.sowder.com
Sent: 28-4-04 1:56
Subject: RE: Weirdness in screen program (not that long!)

Mark:

If you have support check with customer support. This sounds vaguely 
familiar.
Check for reserve words. Do not use a PowerHouse keyword as an
identifier.

Bad syntax
TEMPORARY ITEM ...
ITEM is a reserved word
If you must you can say:-
TEMPORARY %ITEM ...


If you do NOT already have a CLUSTER statement before the TEMP field
put one in.
CLUSTER OCCURS WITH DETAIL
.
.
.
ALIGN(1,4,20)
CLUSTER
FIELD <temporary item>

As a last resort if QUICK wants to eat a field give it one to eat.
i.e.

TEMPORARY t_DUMMY CHAR * 2 INITIAL "  "

CLUSTER
FIELD T_DUMMY NOID NOLABEL
FIELD <temporary item>


Good luck,
Peter Bateman

>From: "Bruin, J.M. de" <Bruin@WT.TNO.NL>
>To: "'powerh-l@lists.sowder.com'" <powerh-l@lists.sowder.com>
>Subject: Weirdness in screen program (not that long!)
>Date: Tue, 27 Apr 2004 20:06:03 +0200
>
>Hi there,
>
>I've posted something similar like this earlier today, but that mail 
>exceeded
>the size limit, so this is just a description of the problem without
the
>(extensive) source code.
>
>I'm encountering some weirdness in a screen program (BTW my environment
is 
>VMS
>7.2, PH 710G1).
>
>The screen consists of three parts:
>- identification fields of the primary file
>- a cluster a the occurring detail file
>- some temporary items to perform some additional prompting for a
built-in 
>copy
>function.
>
>Beside the Prim and Detail there are several secondary and designer
files 
>and a
>bunch of internal and designer procedures.
>
>Thing is the screen has been working without problems for a couple of
years 
>now
>and in fact is still doing that after some changes I have made today.
>These changes are the addition of the previously mentioned temp's and
the 
>fields
>belonging to them.
>
>They are character temp's and the fields have NOID, NOLABEL and DISPLAY
on 
>them
>(beside some other display related parms).
>
>At compilation time there is nothing wrong: all fields are placed as
they
>should, as shown in the screen layout template.
>
>At run-time however the prompt for one of the temp's is done on the 
>position of
>the last field in the cluster (that field is normally a display only 
>field).
>Getting field info using the ??, informs me that it actually is the
temp 
>that is
>needed / required / prompted.
>It is just not on the right position!!!!
>The other temp is filled and then forced to be displayed using Display 
><item>,
>but alas, nothing is visible on the screen.
>
>I can entering a value in the prompted temp and things run as
intended!!!!
>
>Disabling the last field in the cluster will resort in the prompt of
the
>required temp to be on the ID (!!!!!) position of the cluster !!!!!!
>And again, entering a correct value will have the program run as
intended.
>
>The prompt is always done at the LAST occurrence of the cluster. Even 
>without an
>occurrence on the detail file the prompting will end up being done on
the 
>line
>with the fields of the detail file. (like in a cluster)
>
>Moving the temp fields to a position above the cluster (but beneath the

>primary
>identification fields) will resort into a FATAL (yes FATAL) error and
the
>program crashes when starting to prompt for the temp field.
>
>I've tried several other thing s (such as removing the Silent fields
from 
>the
>cluster and disabling some other fields) but the behaviour stays.
>
>I do understand this is a rather extensive and probably hard to dig
into 
>problem
>without actually seeing it, but not posting it will never give me a 
>solution.
>
>If someone is interested in the actual source I can mail that privately
as 
>the
>list server blocks it due to its size.
>
>TIA
>
>Mark de Bruin
>= = = = = = = = = = = = = = = = = = = = = = = = = = = =
>Mailing list: powerh-l@lists.sowder.com
>Subscribe: "subscribe" in message body to
powerh-l-request@lists.sowder.com
>Unsubscribe: "unsubscribe <password>" in message body to 
>powerh-l-request@lists.sowder.com
>http://lists.sowder.com/mailman/listinfo/powerh-l
>This list is closed, thus to post to the list you must be a subscriber.

_________________________________________________________________
Free yourself from those irritating pop-up ads with MSn Premium. Get
2months 
FREE*  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU
=http://hotmail.com/enca&HL=Market_MSNIS_Taglines