Hi,
I've been constructing a tabfolder mechanism in V9 build on TabStrip.OCX. Each "Tab" consists of a .w file which is "parented" to the tabfolder OCX at runtime (not in a frame which is placed immediately on the OCX, but separate .w folders which can be managed separately). So far, "no problem" the system works fine.
Each tabfolder "parented" to the Tabfolder has his own internal procedures like "enable_folder", "disable_folder", ... which are controlled by a persistent loaded procedure, let's say t_folder.p.
So when i do the next from within the tabmanager (which includes the reparented tabfolders) window let's say main.w:
RUN disable_folder("folder1.w").
Then this procedure is run from the t_folder.p persistent procedure and executes the internal procedure in folder1.w.
So the tabmechanism has many other folders (ex. folder2.w, folder 3.w ... and so on) which have the same behaviour, so the same internal procedures.
So the code is duplicated in the internal procedures, which is not a good idea.
My solution was to start a SUPER procedure within each folder like this:
MAIN-BLOCK:
DO ON ERROR UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK
ON END-KEY UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK:
/* start super procedure of THIS-PROCEDURE */
RUN fsuper.p PERSISTENT SET hSuper.
THIS-PROCEDURE:ADD-SUPER-PROCEDURE(hSuper).
RUN enable_UI.
IF NOT THIS-PROCEDURE
ERSISTENT THEN
WAIT-FOR CLOSE OF THIS-PROCEDURE.
END.
So, within the folder folder1.w i made an internal procedure disable_folder with next code:
PROCEDURE disable_folder.
DEF INPUT PARAM iFolderNr AS INT NO-UNDO.
RUN SUPER (INPUT iFolderNr).
END PROCEDURE.
The SUPER procedure internal proc is like this:
PROCEDURE disable_folder.
DEF INPUT PARAM iFolderNr AS INT NO-UNDO.
DEF VAR hFrame AS WIDGET-HANDLE NO-UNDO.
/* get frame handle of current folder */
RUN folder_frame_handle IN hFolder[iFolderNr] (OUTPUT
hFrame).
/* set private data for frame to disabled, so tabmanager
knows this when switching tabs */
IF iFolderNr = INT(ENTRY(1,hFrameRIVATE-DATA)) THEN
hFrameRIVATE-DATA = ENTRY(1,hFrameRIVATE-DATA)
+ ",DISABLED":U.
/* Now i want to disable all widgets in the folder1.w frame, so i
tried this : */
DISABLE ALL WITH FRAME hFrame.
/*I get this error */
Static frame name <frame> conflicts with widget-handle
variable. (3517)
To avoid confusion among widgets and their handles, frames
and widget-handle variables cannot share the same names.
END PROCEDURE.
/* Before using the super, i had this code in the internal procedure disable_folder within the tabfolder, and this worked
fine */
PROCEDURE disable_folder.
DEF INPUT PARAM pFolderNr AS INT NO-UNDO.
DEF VAR vh AS WIDGET-HANDLE NO-UNDO.
vh = FRAME {&FRAME-NAME}:HANDLE.
IF pFolderNr = INT(ENTRY(1,vhRIVATE-DATA)) THEN
vhRIVATE-DATA = ENTRY(1,THIS-PROCEDURERIVATE-
DATA),"DISABLED":U.
DISABLE ALL WITH FRAME {&FRAME-NAME}.
So my question is, how can i use this super-instance to disable
the folder ? In other terms, how can i manipulate the frame handle of the folder procedure to disable the widgets within
the folder frame, and this executed from the SUPER ?
Tanx for any response.
Emmanuel.
END PROCEDURE.
:dead: :dead:
I've been constructing a tabfolder mechanism in V9 build on TabStrip.OCX. Each "Tab" consists of a .w file which is "parented" to the tabfolder OCX at runtime (not in a frame which is placed immediately on the OCX, but separate .w folders which can be managed separately). So far, "no problem" the system works fine.
Each tabfolder "parented" to the Tabfolder has his own internal procedures like "enable_folder", "disable_folder", ... which are controlled by a persistent loaded procedure, let's say t_folder.p.
So when i do the next from within the tabmanager (which includes the reparented tabfolders) window let's say main.w:
RUN disable_folder("folder1.w").
Then this procedure is run from the t_folder.p persistent procedure and executes the internal procedure in folder1.w.
So the tabmechanism has many other folders (ex. folder2.w, folder 3.w ... and so on) which have the same behaviour, so the same internal procedures.
So the code is duplicated in the internal procedures, which is not a good idea.
My solution was to start a SUPER procedure within each folder like this:
MAIN-BLOCK:
DO ON ERROR UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK
ON END-KEY UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK:
/* start super procedure of THIS-PROCEDURE */
RUN fsuper.p PERSISTENT SET hSuper.
THIS-PROCEDURE:ADD-SUPER-PROCEDURE(hSuper).
RUN enable_UI.
IF NOT THIS-PROCEDURE
ERSISTENT THENWAIT-FOR CLOSE OF THIS-PROCEDURE.
END.
So, within the folder folder1.w i made an internal procedure disable_folder with next code:
PROCEDURE disable_folder.
DEF INPUT PARAM iFolderNr AS INT NO-UNDO.
RUN SUPER (INPUT iFolderNr).
END PROCEDURE.
The SUPER procedure internal proc is like this:
PROCEDURE disable_folder.
DEF INPUT PARAM iFolderNr AS INT NO-UNDO.
DEF VAR hFrame AS WIDGET-HANDLE NO-UNDO.
/* get frame handle of current folder */
RUN folder_frame_handle IN hFolder[iFolderNr] (OUTPUT
hFrame).
/* set private data for frame to disabled, so tabmanager
knows this when switching tabs */
IF iFolderNr = INT(ENTRY(1,hFrame
RIVATE-DATA)) THEN hFrame
RIVATE-DATA = ENTRY(1,hFrameRIVATE-DATA) + ",DISABLED":U.
/* Now i want to disable all widgets in the folder1.w frame, so i
tried this : */
DISABLE ALL WITH FRAME hFrame.
/*I get this error */
Static frame name <frame> conflicts with widget-handle
variable. (3517)
To avoid confusion among widgets and their handles, frames
and widget-handle variables cannot share the same names.
END PROCEDURE.
/* Before using the super, i had this code in the internal procedure disable_folder within the tabfolder, and this worked
fine */
PROCEDURE disable_folder.
DEF INPUT PARAM pFolderNr AS INT NO-UNDO.
DEF VAR vh AS WIDGET-HANDLE NO-UNDO.
vh = FRAME {&FRAME-NAME}:HANDLE.
IF pFolderNr = INT(ENTRY(1,vh
RIVATE-DATA)) THEN vh
RIVATE-DATA = ENTRY(1,THIS-PROCEDURERIVATE-DATA),"DISABLED":U.
DISABLE ALL WITH FRAME {&FRAME-NAME}.
So my question is, how can i use this super-instance to disable
the folder ? In other terms, how can i manipulate the frame handle of the folder procedure to disable the widgets within
the folder frame, and this executed from the SUPER ?
Tanx for any response.
Emmanuel.
END PROCEDURE.
:dead: :dead: