I have implemented an extension of t:panelNavigation (x:shalePanelNavigation) that set active all items of the panel that have an action callable based of the current state of the current dialog. At the moment I do: - take the current state (I use an old version) - obtain shaleState.getTransitionOutcomes() (in Iterator trans) - for each item of the panel navigation I check if his action ha a value present in the iterator trans - if true I set active the item...otherwise disactive
Obviously I have some application standards to respects for a correct use of this panel navigation, but at the moment is perfect for us. I hope is a good reason Craig.... :) Thanks in advance Mario -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: 1 dicembre 2006 20.18 To: [email protected] Subject: Re: How know current State? On 12/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi, > > I need to know the current State of the Current Dialog. Is there a way > to know it? There is no public API (on DialogContext) that gives you this information currently ... indeed, there is no guarantee that the underlying dialog system actually has any concept of "state" the way that the old implementation did. I would also consider needing to know the state as a potential red flag on your application design -- the focus should be on building pages that don't need to know such things. If you need information that is application specific, consider using the "data" object instead. Can you describe a use case for why the application would need to know the current state? Is this information something that can be inferred from stuff inside your "data" object instead? In the mean time, it would be possible to create your own version of BasicDialogContext with a public getState() method that would look at the top Position on the "positions" stack, and pull the State out of there, and configure the system to use that instead. You'll need to do cut-and-paste reuse, because this class was not designed to be subclassed. The design idea, as mentioned above, was to hide all the details about internal implementation. Note also that if you expose a State object to your application, you'll be depending on APIs that are internal to Shale and are *not* guaranteed to remain compatible across releases, so we'd better have a really good reason to do it :-). Thanks in advance > > Mario Craig This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
