From: richard.townsendrose on
hi

i just started to overhaul and extend some code whic has been running
since 2004 ..

one thing i am doing is to use one of the tab controls pages on the
tab on another window. works a treat ...

someone recently pointed out that for years the buttons have not had
an owner alignment ... but as the user said they never change the
window size - there is no need

so added that to 4 buttons, and hey presto - when i regenerate the
window holidsng the tab control, the second and third pages fail to
generate in the init and have disappeared from the class as well...

this is all i am left with...
CLASS SDRS INHERIT V4_DataWindow
PROTECT oDCSDRSTab AS TABCONTROLPLUS
PROTECT oTPSDRSBROWSE AS SDRSBROWSE
PROTECT oCCDoExit AS PUSHBUTTON
PROTECT oCCBtOne AS PUSHBUTTON
PROTECT oCCBtTwo AS PUSHBUTTON
PROTECT oCCBtThree AS PUSHBUTTON

the init just has
oTPSDRSBROWSE := SDRSBROWSE{SELF, 0}
oDCSDRSTab:AppendTab(#SDRSBROWSE,"Browse",oTPSDRSBROWSE,0)
oDCSDRSTab:SelectTab(#SDRSBROWSE)

where are the other two tabs ?
now these are both inherited from a standard window .. so there is no
INIT() method

CLASS SDRSResults INHERIT V4TreeViewWindow

METHOD PostInit(oWindow,iCtlID,oServer,uExtra) CLASS SDRSResults
SUPER:PostInit(oWindow,iCtlID,oServer,uExtra)
SELF:oDCTreeView:ContextMenu:=NULL_OBJECT // rgtr 150308
RETURN NIL

So i am rebuilding [and doing the annual upgrade - fabpaint, rightsle,
bbrowser]

If i pull in the old aef exported this morning all worls 100%
just add the owner alignment on one button ... and its .....'d

anyone any ideas ... WHY

i have had to create a window with a resource and inherit in the
ordinary way ... for each of the two treeviewwindow inherted pages

richard
From: Geoff Schaller on
This is actually a bug I think introduced in SP2 to 2.8 and I could
never quite get a consistent behaviour enough to explain it to Robert.
Certainly the problem has been enhanced in 2.8 somewhere.

The exact same thing happens to tab pages on a tab control. Add three
pages and remove the middle one. Suddenly the Init generated for the
window is a mess and refuses to cooperate from that point on. Complete
reconstruction of the window is the only option but delete a page next
time round and you risk the whole thing starting again.

In the end I have resorted to runtime specification of some of these
controls and pages rather than fight with VO. I don't often change the
layout and structure of complex tab control pages precisely because of
these issues.

Geoff



"richard.townsendrose" <richard.townsendrose(a)googlemail.com> wrote in
message
news:a5e80427-7e16-4d7d-a995-ded51978ab67(a)y4g2000yqy.googlegroups.com:

> hi
>
> i just started to overhaul and extend some code whic has been running
> since 2004 ..
>
> one thing i am doing is to use one of the tab controls pages on the
> tab on another window. works a treat ...
>
> someone recently pointed out that for years the buttons have not had
> an owner alignment ... but as the user said they never change the
> window size - there is no need
>
> so added that to 4 buttons, and hey presto - when i regenerate the
> window holidsng the tab control, the second and third pages fail to
> generate in the init and have disappeared from the class as well...
>
> this is all i am left with...
> CLASS SDRS INHERIT V4_DataWindow
> PROTECT oDCSDRSTab AS TABCONTROLPLUS
> PROTECT oTPSDRSBROWSE AS SDRSBROWSE
> PROTECT oCCDoExit AS PUSHBUTTON
> PROTECT oCCBtOne AS PUSHBUTTON
> PROTECT oCCBtTwo AS PUSHBUTTON
> PROTECT oCCBtThree AS PUSHBUTTON
>
> the init just has
> oTPSDRSBROWSE := SDRSBROWSE{SELF, 0}
> oDCSDRSTab:AppendTab(#SDRSBROWSE,"Browse",oTPSDRSBROWSE,0)
> oDCSDRSTab:SelectTab(#SDRSBROWSE)
>
> where are the other two tabs ?
> now these are both inherited from a standard window .. so there is no
> INIT() method
>
> CLASS SDRSResults INHERIT V4TreeViewWindow
>
> METHOD PostInit(oWindow,iCtlID,oServer,uExtra) CLASS SDRSResults
> SUPER:PostInit(oWindow,iCtlID,oServer,uExtra)
> SELF:oDCTreeView:ContextMenu:=NULL_OBJECT // rgtr 150308
> RETURN NIL
>
> So i am rebuilding [and doing the annual upgrade - fabpaint, rightsle,
> bbrowser]
>
> If i pull in the old aef exported this morning all worls 100%
> just add the owner alignment on one button ... and its .....'d
>
> anyone any ideas ... WHY
>
> i have had to create a window with a resource and inherit in the
> ordinary way ... for each of the two treeviewwindow inherted pages
>
> richard

From: richard.townsendrose on
Geoff

Glad to hear that ... i think this bug actually started in 2.7 which
was when i rationalised all our tree view windows to inhert from just
one window thereby saving mega amounts of dupliacted code... after all
VO is an object orientated language...

When constructing complex tab pages i do what you recommend, as below,
and have been using this method since 2006

however, the badly behaved tab was constructed in 2004

the window from which the two tab pages were inheriting has a tree
view control on it ... when i inserted a new window then there was
hassle as the treeview control was not visible, and there is a lot of
code hanging on that - its an Adriano mod of a treeview where he added
a "cargo" so that each element of the tree view is actually driven off
different tables - so for a document, you have level 1: the doc, level
2: the revs, Level 3: the issues, returns to you, returns by you, and
ones own status's. all pof which come from different tables .. or
different sections of the them ..

so glad it wasn't just me ... i am on build 2830 and am not unhappy
with it .. just dont know whether its worth going to 2836 - its the
tesing to find the impact of the last round of hidden new bugs that
bothers me ...

richard

****************

METHOD PostInit(oWindow,iCtlID,oServer,uExtra) CLASS GenMail

SELF:oTPGenMailBr := GenMailBr{SELF, , , uExtra}
SELF:oDCMailTab:AppendTab(#GenMailBr,"&Browse",oTPGenMailBr,0)
SELF:oTPGenMailEdit := GenMailEdit{SELF, , , uExtra}
SELF:oDCMailTab:AppendTab(#GenMailEdit,"&Edit",oTPGenMailEdit,0)
SELF:oDCMailTab:DeleteTab(#_Dmy)

SUPER:PostInit(oWindow,iCtlID,oServer,uExtra)

// temporay till fixed
SELF:oTPGenMailEdit:MailSubTab:DeleteTab(#DOCASSOC) // rgtr 211108

SELF:Caption:='All Mail'
SELF:oTPGenMailEdit:EnableDragDropClient(TRUE)

DO CASE // called via main
window GenManage
CASE ALen(uExtra) == 2 // dashboard [#Manage,
recno] or processflow [#Manage, recno]
DO CASE
CASE IsNumeric(uExtra[2]) // recno from dashboard or process
flow
SELF:oDOCGD:GoTo(uExtra[2])
SELF:TabVarPut(#lIfOwn, IIF(SELF:oDOCGD:FIELDGET(#DOCSRC) ==
'O',TRUE, FALSE) ) // fixed display ... 200310

SELF:oDCMailTab:SelectTab(#GenMailEdit)
IF SELF:oDOCGD:FIELDGET(#DOCSENT) .OR.
(SELF:oDOCGD:FIELDGET(#TYPE) ==
SysObject():GetParam(RFIReplyType) .AND.
Empty(SELF:TABVarGet(#cComplexType))) // rgtr 190310
SELF:oTPGenMailEdit:UserAction:=#VIEW
ELSE
SELF:oTPGenMailEdit:UserAction:=#EDIT
ENDIF

CASE IsArray(uExtra[2]) // data for NEW from process flow
IF uExtra[2,8] =='O'
SELF:DoCreate(uExtra[2])
ELSE // 'I'
SELF:DoReceive(uExtra[2])
ENDIF
ENDCASE

CASE uExtra[1] == #Manage
SELF:TabVarPut(#lIfOwn, FALSE)

CASE uExtra[1] == #Receive
SELF:DoReceive()

CASE uExtra[1] == #Create
SELF:DoCreate()
ENDCASE

RETURN NIL
From: richard.townsendrose on
Geoff

its definitely a problem ... cannot pin it down ...

redid the window, and soon as i added the owner alignments the problem
of missing sub tabs re-occured

i have added the owner alignments into the post init .. that works ok

also now when i select a second tab a SECOND time, the content has
disappeared, but if one resizes the window with the mouse it
reappears .. how can i do that programmatically .. i seem to remember
in 2.5 or was 1.0 one had to have resize methods ????

any comments appreciated

richard
From: richard.townsendrose on
Geoff

added this to the tabselect() method ...

adding the 2nd and 3rd tabs in the postinit() made no difference to
the disappearing treeview content.

oDim:=SELF:Size
SELF:Size:=Dimension{oDim:Width + 1, oDim:Height}
SELF:Size:=Dimension{oDim:Width, oDim:Height}

slight flicker but hell it now WORKS ok ...

richard