Thanks Mike. It sounds like that APAR might cover this issue. I will keep
an eye out. I appreciate your response.
Craig Strong
Mike wrote:
-----------------------
There was a problem reported recently to do with relative positioning and
I think that resulted in some changes in how relatively positioned fields
are handled in Designer.
SE52670: RDP 8.5 SCREEN DESIGNER CONFUSED AFTER CHANGING A FIELD FROM
ABSOLUTE TO RELATIVE POSITIONING
http://www-01.ibm.com/support/docview.wss?uid=swg1SE52670
Mike
Mike Hockings, M.Eng., P.Eng.
IBM Rational Developer for System z and Power Systems Software Technical
Support
IBM Canada Ltd. Laboratory
hockings@xxxxxxxxxx
voice 1-905-413-3199 T/L 313-3199 ITN 23133199
wdsci-l-bounces@xxxxxxxxxxxx wrote on 2012-09-28 11:24:57:
From: craigs@xxxxxxxxx
To: wdsci-l@xxxxxxxxxxxx,
Date: 2012-09-28 11:27
Subject: [WDSCI-L] Fw: RDP DDS Designer Relative to Absolute
Sent by: wdsci-l-bounces@xxxxxxxxxxxx
I haven't heard or seen anything about this since my post on 5/16/12
on
this list or in the newest version of RDP. Someone from IBM suggested
I
try the wdsci-l list of midrange.com first which I did in May. Then,
try
the DeveloperWorks RFE thing which I'm surprised I don't see anything
noticeable about this there yet. I searched and haven't seen other
complaints on midrange.com or DeveloperWorks so I'm thinking that I
may
be
the only one dealing with screens/reports with relative positioning.
I am changing reports/screens designed originally with straight DDS
which
is easier to code with relative positioning. In CODE, if you select a
field positioned with +2 for example and move it left one, it changes
to
+1. Also, the field next to it defined with +2 changes to +3 in CODE.
If
you happen to overlap another field in CODE, it changes to absolute
positioning and causes a red box to indicate overlap. Excellent. In
RDP
Report Designer, that same operation does not increase the next
field's
relative position thereby shifting the whole line left. Granted, not
as
flexible as CODE but there is the ability to overcome it. I could see
a
working as designed response. But wait, it remembers the positioning
internally for the other relative positioned fields for that line.
So,
I
try to move the third field relatively positioned to the second field
left
one and it shifts that field (and the whole line) left two. Same
thing
for
other relatively positioned fields for that line. They remembered the
previous positioning of two so I shift one of those left one space
and
they
go three spaces left where one field would overlap another which ends
up
throwing that field and the rest of the line at position 1 thereby
overlapping what was there starting in position 1.
I'm wondering if there may be a statement from IBM somewhere about
not
supporting relatively (ex: +1) positioned screen/report fields. Or,
people
are still using CODE Designer even though it is stabilized and may be
unsupported. Or, this type of thing wouldn't hit the IBM priority
list.
I
can take the time to convert from relative to absolute positioning
for
RDP
if needed but I thought it wouldn't hurt to inquire.
Do you think I should stay quiet and see what happens to unfold or
push
a
little more with an RFE? Am I missing something?
Thanks.
Craig Strong
Craig wrote:
------------------------------
I am a long time Code Designer user and I have switched to the RDP
DDS
Designer. There is one major issue I am having with the RDP DDS
Designer
which is frustrating and is a major loss in productivity. That is the
fact
that relative positioned field (ex: +1) cannot be individually moved
without moving everything after that which is relative. In Report
Designer, the whole line moves. In Screen Designer, nothing moves
unless
I
make them absolute positions. Code Designer would move them without
problem. The easiest way I have found to convert from relative to
absolute
is to click the last relative field of the line and unchecking
"Relative".
Then I have to remember where it was at before and reposition the
field.
Then I go down the line to the left unchecking and repositioning.
This
is
a waste of time.
I have checked the archives to no avail. It seems like it would be
possible to convert relative to absolute fairly easily. I could
probably
write a program to do this but I don't have the time right now.
Does anyone know of a function or alternative to get around this?
Does
anyone know of a future RDP fix for this?
Thanks.
Craig Strong
----- Forwarded by Craig Strong/DEKKO on 09/28/2012 03:01 PM -----
From: Craig Strong/DEKKO
To: wdsci-l@xxxxxxxxxxxx,
Date: 09/28/2012 11:24 AM
Subject: Fw: RDP DDS Designer Relative to Absolute
I haven't heard or seen anything about this since my post on 5/16/12 on
this list or in the newest version of RDP. Someone from IBM suggested I
try the wdsci-l list of midrange.com first which I did in May. Then, try
the DeveloperWorks RFE thing which I'm surprised I don't see anything
noticeable about this there yet. I searched and haven't seen other
complaints on midrange.com or DeveloperWorks so I'm thinking that I may be
the only one dealing with screens/reports with relative positioning.
I am changing reports/screens designed originally with straight DDS which
is easier to code with relative positioning. In CODE, if you select a
field positioned with +2 for example and move it left one, it changes to
+1. Also, the field next to it defined with +2 changes to +3 in CODE. If
you happen to overlap another field in CODE, it changes to absolute
positioning and causes a red box to indicate overlap. Excellent. In RDP
Report Designer, that same operation does not increase the next field's
relative position thereby shifting the whole line left. Granted, not as
flexible as CODE but there is the ability to overcome it. I could see a
working as designed response. But wait, it remembers the positioning
internally for the other relative positioned fields for that line. So, I
try to move the third field relatively positioned to the second field left
one and it shifts that field (and the whole line) left two. Same thing for
other relatively positioned fields for that line. They remembered the
previous positioning of two so I shift one of those left one space and they
go three spaces left where one field would overlap another which ends up
throwing that field and the rest of the line at position 1 thereby
overlapping what was there starting in position 1.
I'm wondering if there may be a statement from IBM somewhere about not
supporting relatively (ex: +1) positioned screen/report fields. Or, people
are still using CODE Designer even though it is stabilized and may be
unsupported. Or, this type of thing wouldn't hit the IBM priority list. I
can take the time to convert from relative to absolute positioning for RDP
if needed but I thought it wouldn't hurt to inquire.
Do you think I should stay quiet and see what happens to unfold or push a
little more with an RFE? Am I missing something?
Thanks.
Craig Strong
Craig wrote:
------------------------------
I am a long time Code Designer user and I have switched to the RDP DDS
Designer. There is one major issue I am having with the RDP DDS Designer
which is frustrating and is a major loss in productivity. That is the fact
that relative positioned field (ex: +1) cannot be individually moved
without moving everything after that which is relative. In Report
Designer, the whole line moves. In Screen Designer, nothing moves unless I
make them absolute positions. Code Designer would move them without
problem. The easiest way I have found to convert from relative to absolute
is to click the last relative field of the line and unchecking "Relative".
Then I have to remember where it was at before and reposition the field.
Then I go down the line to the left unchecking and repositioning. This is
a waste of time.
I have checked the archives to no avail. It seems like it would be
possible to convert relative to absolute fairly easily. I could probably
write a program to do this but I don't have the time right now.
Does anyone know of a function or alternative to get around this? Does
anyone know of a future RDP fix for this?
Thanks.
Craig Strong
As an Amazon Associate we earn from qualifying purchases.