That's a reasonable solution for this specific case, and does very
well as a workaround until we propose and implement a more general
solution (the screen manager that I mentioned last week). I've got
this on my to-do list for 3.2.
jim
On Nov 28, 2005, at 8:11 AM, William Krick wrote:
This is the solution that we ended up with (see example code
below). The
idea was posted by someone in the laszlo forums. Basically, you
cover the
tabelement's header with an invisible view to intercept the
clicks. It's
similar to the "glass pane" concept in java swing. It works well
but it's
not really optimal as you don't actually see the click animation on
the
header.
I think the right solution would be to allow us to attach an "onclick"
method to the header. I think the regular tab control allows you
to attach
onclick methods to the "tabs". Unfortunately, I don't think there's
a way to
get at the header in a tabelement except to place visual items in it.
<?xml version="1.0" encoding="UTF-8" ?>
<canvas width="1024" height="768">
<modaldialog name="errordialog" width="300" height="200">
<simplelayout/>
<view width="100%" height="85%">
<text text="Item 1 is not a valid selection."></text>
</view>
<button text="OK" isdefault="true" x="100"
onclick="this.parent.close()"
/>
</modaldialog>
<tabslider width="800" height="600" oninit="selectItemAt(0)"
id="slider">
<tabelement text="Questions" id="questions">
<combobox oninit="selectItemAt(0)" name="listofthings">
<textlistitem text="Item 1"></textlistitem>
<textlistitem text="Item 2"></textlistitem>
<textlistitem text="Item 3"></textlistitem>
</combobox>
</tabelement>
<tabelement text="Results" id="results">
<view placement="header" width="${parent.width}"
height="${parent.headerheight}">
<method event="onclick">
if(questions.listofthings.getValue() == "Item 1") {
canvas.errordialog.open();
}
else {
slider.select(results);
}
</method>
</view>
<method event="onselected">
<![CDATA[
// do stuff
]]>
</method>
<text>Hello World!</text>
</tabelement>
</tabslider>
</canvas>
-----Original Message-----
From: Jim Grandy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 23, 2005 8:23 PM
To: Papadogiannakis Vagelis
Cc: [email protected]
Subject: Re: [Laszlo-user] Bug when forcing user to a tabslider?
Thanks for investigating this further! When I wrote my "this is a
bug" message, I confess I hadn't gone back through the code to verify
whether it had been designed to do what Tim was expecting.
I really like the suggestion that tabslider should have a mechanism
whereby the currently selected tab has a chance to veto a change in
selection. I think extending tabslider itself to do this would be
relatively straightforward, potentially even simpler than the
external solution you found below.
In fact, this problem isn't unique to tabslider -- it is common to
tabslider, tabs, and any other similar component such as a wizard
interface controller. I could imagine a screen-management (base-)
class that would manage screen switches through the protocol you
suggested, and perhaps even handle initstage so that screens were
built only when needed (another issue we want to address with this
type of component).
Let's at least add this thread to the bug in JIRA (http://
www.openlaszlo.org/jira/browse/LPP-1057). Of course, if you would
like to contribute a more complete proposal to address this within
the components themselves, I know I'd be interested in seeing it!
jim
_______________________________________________
Laszlo-user mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-user
