Thanks Havard, but I recently discoverd what was going wrong, it was all my fault but I was too blind to see it then. What I did is to use the FolderWindowToLaunch property and launchFolderWindow method of a DynBrowse to launch different containers from the toolbar via the toolbar link that were each dependent on the base container and accidentally passed in "View" instead of "Modify" as container mode. Thank god for the new debugger!
-Richard.
-Ursprüngliche Nachricht-
Gesendet: Sonntag, 23. Februar 2003 15:57
An: dev@icf.possenet.org
Betreff: RE: Toolbar TableIOType=Save & Toolbar link to container
This is probably due to the fact that the container uses the ContainerMode to publish an event from its toolbar-source.
The ContainerMode is either set from the caller or from the Repository. If you double click from a browse the mode isset to 'view'.
I would consider it a bug that this is done for a toolbar with no update action.
HÃ¥vard
-Original Message-
Sent: Friday, February 21, 2003 9:23 AM
To: dev@icf.possenet.org
Subject: Toolbar TableIOType=Save & Toolbar link to container
I have a window with a SDO / browser / viewer & toolbar on it. The toolbar has the TableIO plus the TxtClose band on it. It is a save toolbar so that the fields in the viewer are enabled instead of forcing the user to press the update button. But as soon as I add the Toolbar Link to the container, the fields aren't enabled when the container is started. Since the toolbar is a save toolbar it has no update button either ... so I can't update a record. But after having added a record the fields in the viewer stay enabled as they should. So I think this has something to do with the initialization of the container, but I couldn't find the code which is responsible for that behavior. Does anybody know if this is expected behavior and if there is simple workaround available ?
Any help is appreciated,
Richard.