Home » Eclipse Projects » GEF » Auto-sizing layouts?
| Auto-sizing layouts? [message #77767] |
Fri, 02 May 2003 17:39  |
Eclipse User |
|
|
|
The editor I'm building has a "master" editor (which draws itself as a
rounded rectangle) that contains 3 child editors. As the child editors
expand and contract to fit the content and the parent needs to resize to
match.
I tried handling this in a layout manager (resizing in the layout() call),
but this is called on the parent before it's called on the children, so you
can get:
parent.layout(), child.layout (), child.layout() ....
In other words, the children get theiur own layout calls after the parent,
so the parent can't catch up with their new size.
Is there a way to control the order of layout() calls (e.g. from the
bottom-up in the part tree), or should I just call invalidate the child
if/when the layout manager resizes it?
....Richard
|
|
| |
| Re: Auto-sizing layouts? [message #77799 is a reply to message #77767] |
Sun, 04 May 2003 13:27  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Typically, layout is top-down, so your parent should position its children
first. The reason it is top-down instead of bottom up is that figures can
have a range of valid sizes, between minimumSize and preferredSize. Some
layouts may choose to give a figure a size somewhere between these two
sizes. Also, some layouts may stretch a figure to be larger than it wants,
for example a column of children, where each child has a different preferred
size, might instead stretch smaller children to be the sizse of the widest
child. The child can't layout until the parent has made these decisions.
Can you attach a screenshot of what you are trying to achieve?
"Richard Clark" <rdclark@nextquestion.net> wrote in message
news:b8uohe$i13$1@rogue.oti.com...
> The editor I'm building has a "master" editor (which draws itself as a
> rounded rectangle) that contains 3 child editors. As the child editors
> expand and contract to fit the content and the parent needs to resize to
> match.
>
> I tried handling this in a layout manager (resizing in the layout() call),
> but this is called on the parent before it's called on the children, so
you
> can get:
> parent.layout(), child.layout (), child.layout() ....
> In other words, the children get theiur own layout calls after the parent,
> so the parent can't catch up with their new size.
>
> Is there a way to control the order of layout() calls (e.g. from the
> bottom-up in the part tree), or should I just call invalidate the child
> if/when the layout manager resizes it?
>
> ...Richard
>
>
>
>
|
|
|
| Re: Auto-sizing layouts? [message #77830 is a reply to message #77799] |
Sun, 04 May 2003 14:24 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_002A_01C3122F.C779B170
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_002B_01C3122F.C779B170"
------=_NextPart_001_002B_01C3122F.C779B170
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
"Randy Hudson" <none@us.ibm.com> wrote in message =
news:b93ih7$1ur$1@rogue.oti.com...
> Can you attach a screenshot of what you are trying to achieve?
It's an editor where each node in a state machine has several "handlers" =
--one called at entry, one called repeatedly while idling, and one =
called at exit. The challenge is that each handler's size and position =
could depend on the number of commands within, and the node's size is =
determined by the joint handler sizes. I'd like to avoid having =
scrolling parts within the nodes, but leave the scrolling to the =
top-level.
This is why I'm trying to lay out the screen beginning with the children =
-- the handlers size themselves to fit the commands, the nodes postiion =
the handlers within themselves, then the top-level editor positions the =
nodes.
....Richard
------=_NextPart_001_002B_01C3122F.C779B170
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>"Randy Hudson" <</FONT><A=20
href=3D"mailto:none@us.ibm.com"><FONT face=3DArial=20
size=3D2>none@us.ibm.com</FONT></A><FONT face=3DArial size=3D2>> =
wrote in message=20
</FONT><A href=3D"news:b93ih7$1ur$1@rogue.oti.com"><FONT face=3DArial=20
size=3D2>news:b93ih7$1ur$1@rogue.oti.com</FONT></A><FONT face=3DArial=20
size=3D2>...</FONT><FONT face=3DArial size=3D2><BR>> Can you attach a =
screenshot of=20
what you are trying to achieve?<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It's an editor where each node in a =
state machine=20
has several "handlers" --one called at entry, one called repeatedly =
while=20
idling, and one called at exit. The challenge is that each handler's =
size and=20
position could depend on the number of commands within, and the =
node's=20
size is determined by the joint handler sizes. I'd like to avoid having=20
scrolling parts within the nodes, but leave the scrolling to the=20
top-level.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"" hspace=3D0=20
src=3D"cid:002501c3126a$719b6ab0$0200a8c0@zen" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This is why I'm trying to lay out the =
screen=20
beginning with the children -- the handlers size themselves to fit the =
commands,=20
the nodes postiion the handlers within themselves, then the top-level =
editor=20
positions the nodes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>...Richard</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> </DIV></FONT></BODY></HTML>
------=_NextPart_001_002B_01C3122F.C779B170--
------=_NextPart_000_002A_01C3122F.C779B170
Content-Type: image/gif;
name="untitled-1.gif"
Content-Transfer-Encoding: base64
Content-ID: <002501c3126a$719b6ab0$0200a8c0@zen>
R0lGODlhAwG4ALMAAAAAAP///9fX5318qZYeHQAAZszMzEtLSGZmZicnfUVE Qfn37KCfrmZmmeXk
2btUVCH5BAQUAP8ALAAAAAADAbgAAAT/MMhJq7046827/2AojmRpnmiqrmzr vnAsz3Rt33iu73zv
/8CgMOZgIACKpAKpZCadS2W0KYVaq1iq9pnlbqfeMHh8/QIO6MM5vUa31Wk4 O/6uIxgOW/GomPvd
dGgbBmgDAwYLiYqLjI2Oj5CRkpOUlZaXmJmJDgYMA0cGMgYICIYOmooZC6QM qK6vsLGys6h7CAsu
qwiIshirA6e0wsPExcaNDgMKuCureLQXzsfT1NXWlEbMKNLCF6XX4OHixqQq 38MWo8Hj7O3ulQ4A
oSfqxBZ37/n6+4lGKLvFKji4VYwXv4MIGQ3MU2KgsQqeJCVooMhBAkoDCkAy UKBAgnUN/zpS3JSg
44CEKGV9MsGgVaSJFS9OGlDhHKSOvDhi1PioAKKQiYAugLnAY6ICLlMqzVSu BL5IOBPpnFkBwLqe
HaXyXGDA0KKuDIQu8OSSAU8HBU4VOMlVI1peDWQunVuJkAmrkjrynMrVqyKw DSocmITU6NSQnXy2
bZm1aAOOJxPIXVuULUcDlxNlpMt5koMDJgbnNXvxsE+ziDgyFkw4MWaeSBOV LCpz89TNkhVRnj1U
sdGiWzsLbwS6hGiorqfG7k1bM+u8iHBqzLxgM+XqGjNKzp37KNuSBUKeQtuR 9/DzigCEbg1cJ3Xr
bGlSOH4TEXm3ihcAvb7ZLKPNRxnUT/9wssmF3nnFkUBfT/bptcBbQWnEX1Xs YQebTOExxxFsI22S
1lgEVtZIfgcieFeFGV14FEWzcfQccrqdBd5I9/F2H09mIaZZAhl1OFFGSZU4 XIIjLOgIiY1ZJJKH
5b04joBcQRmlkCUSKYKR0MxH5ZZLqWfcMU5yKeY+VoaA5SwUjqmmPmWCAACY Wq4pZzttfnBmL3HO
qSc4dXpwZyxh7imoMV4qCOcEf9KC2aKMNuroo5BGKqmjg2bSZweJvpImNfMM UYGUlUpyKQdvPpTn
NJ16OgGooUIy6gaZuhJoQTY0EFgIrLbqyKsaxIrKrMSkKoAhFNAUUQZkTWDs SQEIYJL/BCe1JF8A
mH2qayWFFnmoBL7C0iliqDVbXkkYhAeZuB6RG0BHAqDbgFkMSICUtddOwmsG 3WayKaoTzBsAuc7S
5Gy7nxYArcEBi9uuZBI4G++/BpuVTr32nmgqosc0Mc/AByvscQXabecxxwx/ 7N9E6XRBhspliNHy
ymawLPMXjNyLQb6YACuLAqtKUNQ8IY1cAMEUSEwBxyQn0PDQ/c6Wjqo4lKqI zRfgfInOsfAsQace
yRsY0kxbEN7RTJNs8McBhHT2p1DfsMwi2V65bQBWW1Jop72NLTTRFADX0d4B ALcAx1v7y3bbNbw9
9XoXSyA1MVpTG0Jc2z18gtFPI06D/+KJUG3B4+icOkzkqfKA8gWla/4C5wt4 jjUsr79COhB8H656
DKC7Lno3u9Myu+ap384C63GbOXfd2K466fLMNx+p8DGwrjvGjQcAujCRQ6+9 C9JbHFDvs2S//fgp
dP9l9chTIn4IxVflfgvtTxB/BgDEHX/9NuTO+PfUF7O+mxuYXwrqJ0ABfs5x 8pufAVdAvP3ZA3yy
KCD+HFcoAt6PgNaboAWzNcEMehADCsQgBUmFwBBy0Ev406B6VGhA8xmqetfz Hf1O2EED2k9+1sth
BmtoQw1wEIH0o6AID6hDFAKxgkjsgAtHEEM0QTBrATTi+4JIgQrmUIpVJCEV j7hFHP+CkItFBKIO
q9jCmjkwdP2D3AxpSEYfrnCDK/ygCC0IQjrWMYFrRGL7MKhCMqZwjh2knxnP xz9uZYx8iCwfIxbY
q+Md44JwjKQkJ0nJShYPjiiw5OcsyUk7YmCJcoPhIRNJShKAkn2ONMb/SslK DZwSBOmbROxcscpW
2nJfrTsj79I4ulv6MgMNJOQDeSkMRv6SlK+009yauLNjOnMCyfQAMwH1RFjU 8pmljCamUuk/bDpT
f8JEoyFV+bJyzsxl54QZOmPGznW6U53wNGfMFhkaBzygkHSjmD41MT1uEeAq WZLfPgdqiX4u4J/o
I6hCRUUCBxAglpKY5UL1qTt7fob/mxPNaCKMSQGH5gGikZCoRnXlOYuOE5/T HCnFqGZSx2H0GM6L
qUyXp1KbebSamsKpLIKXAoIlogS52ue9WkrMgJ6UXydIgOU69i+lkSCo+mTk TUWqL53GgqcgGEDt
MiKBko0AqivlAFGtqglcGkNYxFJWAI51Aa02bABhOZtXPVE7DYC1XqMaaxVf etYJgMsn6JLM2iqw
FmohxSxydephw8aBu17rUlOtGl9pJa+HAaywhCMsTboWAK42NW2J9YBjSZoB vVI1Z2TNBBPksTSC
cRVsdV3XZuXjWYaVZDu3amw65flO3sZztzNzRPwie7PJziJB8/iZBIIG2wsU trCd/w2tukCAVW9K
gHWdu4BpLQBSSJiVFshtmtcAJzaaXDa0DsOVdV25KwsQV5AJJVTPfDaj1qKN AoX1m7pKhli9NXa9
8B3kBLYr2fgWI7wgoJxklvqC6loXu7kc8AMYsk0DEwPBiHOwNyFcqPfCyriy wHDbNIxNCBeHwPha
5jFEDDUSP9PEAfAwqUAci7vN9MY4rhaALxDDA6C4kRYeRj93HAQIK2DCL8Rn dx8xZCL/ALsy9hON
YXGpSwYyi1heAUelOUUtm4B19hzykh3x3eMC0Icz2HIH1My+K4eAcx4dckpz WtRZQNKPkHwjCj35
wRF6kIUhFKIJ9SzoE+LRzV4kgf/ULBrhJA/zqEJGc5a/mOU47lmDYLQiFaWo wClaWtB4lLQpN4HQ
RmsryMKocpd57OkrijHTYiwgrCmd6E+PMdFdFMEyPJoeXRo1n8ao0wZBPcMd 0vGNQgw1sfu8yWQj
eoSRvOKll10VPoNAAYxeXDh36dJgOxmZpda2oqf8ijx38tzorqTwMMnE9m77 12MmzrcTCeN3O7HO
IZ43Ijns63tDOtUsYDOpBF7sLgby2TCot6PFab0VB/wFBM91AjXNabe5e9yo psWW7chDHtbx4Gz0
8yZB7kdlx3rWNehxv/GE71jYrOJj/OGtsQxzTg/xfTU/4s0pDsbEXfzUSnY4 l8P/GHOaUzrnRN/0
rLFYaZRvTrgrp2bLqewmj7dR5NVGNrM5jmg+7hnPyTb2103+dHnbm+XdPrAI Iq5vRZod40GX75rT
zW4Z0P3uw075z0MZd7W3fXsKB/qjge33v0OP32eX+r/Ba3jtBZ7vg5+zK5rc eBs8HpUZt3Pl1713
42U+35tX3eVhSe7Jh170UE887FKLiT7UIRB/kAMgYv962qOht8Bt529179ve K6HzpBelSjMq59IP
P1RiNv7xB5X8zy9fV2yPNyNO+3w5NR+l1Sdo8Z2ffeZHffVT7/6erj946Yuf M9FX/ityzH6Z1vT7
dE47UjP8/hJI/lesR4WLUWAr/xGMtlXkx3Dm5wj7dznxMhTaMAj1t3DcRnjz 1yxpBS1rxSwYkCwT
6DPy0RKg9S4d8H+hkn7cNwvfchqA5SzpMlj49RiY9Vy3wjDwkoAZ4IGVEoAN eH/e0i+WhTArWFcu
El3L5RFrwzCZpYAjtX19BzlPsDFh81plw1jKki5e1RGWI4ROaFe5h3u8d4W7 h4VJIGCCJ4CjJDmB
A1igRV5Fg4KBNQFUGFuo03jgxIDwFoZco1hf04Sx5V9eAy9dpTTO4mIF6EzB BIf+5oDDcDcTkDe3
0lwW4DcGs18a8Vkb2IGNp00cMIA/tVeqNF8foGBKNQN/eEyUGEDq13qaOGKT 6P+FkAeGmbg1qvOJ
v/SGX9iAlrgAv5Nhpwg38Ccr+Wc3ytN+vjgptyhusfhrNpgJ13R6RYaKmHeE vYSMmhOKQMaM2GN3
AbRqA2RLsJiKshiGEFeNuINwgEdPqhd/hFhMxdZHE6ds1jZxhCZ2V/dnndZK 0JhiwtdNBWdsWOdJ
PdR0cYSPWMdq8qiMbjKKl3BNMldtr5aQRFRrrjZzDrmQ2SSQyhSCtJRH6bhD JUd2CBltWgdIz5Z3
pJSNnieNMuSMiBOIwziIs2hueAeSN1B39CaRUlaPamSSbTOPIESQlnCMNskD OFlgJBk+PQk1Ihl8
QdlMQ+kpKKmNcSh3SSkEP8n/XSq2ik+ZjItghOXHjVXpA1FJfZbglZXAk1up d1eZi/gXfrTke1m4
lly4hW6plm0JlysjjoKIduV4fjNolmWFiXhJWvank31ZJXpZVYgCUIE5foOJ Wogig4d5HgYQfYY5
iDbRmHrSFCTwFIM3mZQpJ3BlApjJcAuxmZVJYSPgEPgUAJ8pmmLCAJQHEINH LXihmmLyGa74KcX4
lfcADLLJJSuRAqlplz7zm7s5HNmgAtzwa4eoAM8wnMORDLfAArS4nMB5iKwQ mcyZEEbwnC2gCwZg
nYqJAY9ZCnjgndc5DgMxAGhQm6IFAOLpAOQZUWJlBHI5n1pIn2z5lvWZn/fJ JJ54oAfyqZ9jGaAC
OqAEWqAGeqAImqAKuqAM2qAO+qAQapIRAAA7
------=_NextPart_000_002A_01C3122F.C779B170--
|
|
|
| Re: Auto-sizing layouts? [message #77847 is a reply to message #77830] |
Sun, 04 May 2003 23:44 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
This is a multi-part message in MIME format.
------=_NextPart_000_0017_01C31297.2788BC20
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0018_01C31297.2788BC20"
------=_NextPart_001_0018_01C31297.2788BC20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
figure "Node 099" should be a figure in ToobarLayout, where =
setMatchMinorAxis is set to true if you want the 3 children to be the =
same width.
the parent of "Node 099" should be a figure in tollbarLayout, with =
orientation set to HORIZONTAL.
I didn't understand your original use of the word "editor". There is =
generally only a single IEditorPart. Did you mean EditPart?
Can you delete the "on_entry" box? Can you drag it/move it/copy it? If =
not, maybe it doesn't need to be an editpart. Just a thought. I don't =
know what the convention is for this type of application.
"Richard Clark" <rdclark@nextquestion.net> wrote in message =
news:b93lsu$3n8$1@rogue.oti.com...
"Randy Hudson" <none@us.ibm.com> wrote in message =
news:b93ih7$1ur$1@rogue.oti.com...
> Can you attach a screenshot of what you are trying to achieve?
It's an editor where each node in a state machine has several =
"handlers" --one called at entry, one called repeatedly while idling, =
and one called at exit. The challenge is that each handler's size and =
position could depend on the number of commands within, and the node's =
size is determined by the joint handler sizes. I'd like to avoid having =
scrolling parts within the nodes, but leave the scrolling to the =
top-level.
This is why I'm trying to lay out the screen beginning with the =
children -- the handlers size themselves to fit the commands, the nodes =
postiion the handlers within themselves, then the top-level editor =
positions the nodes.
...Richard
------=_NextPart_001_0018_01C31297.2788BC20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2723.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>figure "Node 099" should be a figure in =
ToobarLayout, where setMatchMinorAxis is set to true if you want the 3 =
children=20
to be the same width.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>the parent of "Node 099" should be a =
figure in=20
tollbarLayout, with orientation set to HORIZONTAL.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I didn't understand your original use =
of the word=20
"editor". There is generally only a single IEditorPart. Did =
you mean=20
EditPart?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Can you delete the "on_entry" =
box? Can you=20
drag it/move it/copy it? If not, maybe it doesn't need to be an=20
editpart. Just a thought. I don't know what the convention =
is for=20
this type of application.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Richard Clark" <<A=20
=
href=3D"mailto:rdclark@nextquestion.net">rdclark@nextquestion.net</A>>=
wrote=20
in message <A=20
=
href=3D"news:b93lsu$3n8$1@rogue.oti.com">news:b93lsu$3n8$1@rogue.oti.com<=
/A>...</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>"Randy Hudson" <</FONT><A=20
href=3D"mailto:none@us.ibm.com"><FONT face=3DArial=20
size=3D2>none@us.ibm.com</FONT></A><FONT face=3DArial size=3D2>> =
wrote in message=20
</FONT><A href=3D"news:b93ih7$1ur$1@rogue.oti.com"><FONT face=3DArial=20
size=3D2>news:b93ih7$1ur$1@rogue.oti.com</FONT></A><FONT face=3DArial=20
size=3D2>...</FONT><FONT face=3DArial size=3D2><BR>> Can you attach =
a screenshot=20
of what you are trying to achieve?<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It's an editor where each node in a =
state machine=20
has several "handlers" --one called at entry, one called repeatedly =
while=20
idling, and one called at exit. The challenge is that each handler's =
size and=20
position could depend on the number of commands within, and the =
node's=20
size is determined by the joint handler sizes. I'd like to avoid =
having=20
scrolling parts within the nodes, but leave the scrolling to the=20
top-level.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"" hspace=3D0=20
src=3D"cid:001201c312b8$ae913460$6401a8c0@porrada" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This is why I'm trying to lay out the =
screen=20
beginning with the children -- the handlers size themselves to fit the =
commands, the nodes postiion the handlers within themselves, then the=20
top-level editor positions the nodes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>...Richard</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2> </DIV></BLOCKQUOTE></FONT></BODY></HTML >
------=_NextPart_001_0018_01C31297.2788BC20--
------=_NextPart_000_0017_01C31297.2788BC20
Content-Type: image/gif;
name="untitled-1.gif"
Content-Transfer-Encoding: base64
Content-ID: <001201c312b8$ae913460$6401a8c0@porrada>
R0lGODlhAwG4ALMAAAAAAP///9fX5318qZYeHQAAZszMzEtLSGZmZicnfUVE Qfn37KCfrmZmmeXk
2btUVCH5BAQUAP8ALAAAAAADAbgAAAT/MMhJq7046827/2AojmRpnmiqrmzr vnAsz3Rt33iu73zv
/8CgMOZgIACKpAKpZCadS2W0KYVaq1iq9pnlbqfeMHh8/QIO6MM5vUa31Wk4 O/6uIxgOW/GomPvd
dGgbBmgDAwYLiYqLjI2Oj5CRkpOUlZaXmJmJDgYMA0cGMgYICIYOmooZC6QM qK6vsLGys6h7CAsu
qwiIshirA6e0wsPExcaNDgMKuCureLQXzsfT1NXWlEbMKNLCF6XX4OHixqQq 38MWo8Hj7O3ulQ4A
oSfqxBZ37/n6+4lGKLvFKji4VYwXv4MIGQ3MU2KgsQqeJCVooMhBAkoDCkAy UKBAgnUN/zpS3JSg
44CEKGV9MsGgVaSJFS9OGlDhHKSOvDhi1PioAKKQiYAugLnAY6ICLlMqzVSu BL5IOBPpnFkBwLqe
HaXyXGDA0KKuDIQu8OSSAU8HBU4VOMlVI1peDWQunVuJkAmrkjrynMrVqyKw DSocmITU6NSQnXy2
bZm1aAOOJxPIXVuULUcDlxNlpMt5koMDJgbnNXvxsE+ziDgyFkw4MWaeSBOV LCpz89TNkhVRnj1U
sdGiWzsLbwS6hGiorqfG7k1bM+u8iHBqzLxgM+XqGjNKzp37KNuSBUKeQtuR 9/DzigCEbg1cJ3Xr
bGlSOH4TEXm3ihcAvb7ZLKPNRxnUT/9wssmF3nnFkUBfT/bptcBbQWnEX1Xs YQebTOExxxFsI22S
1lgEVtZIfgcieFeFGV14FEWzcfQccrqdBd5I9/F2H09mIaZZAhl1OFFGSZU4 XIIjLOgIiY1ZJJKH
5b04joBcQRmlkCUSKYKR0MxH5ZZLqWfcMU5yKeY+VoaA5SwUjqmmPmWCAACY Wq4pZzttfnBmL3HO
qSc4dXpwZyxh7imoMV4qCOcEf9KC2aKMNuroo5BGKqmjg2bSZweJvpImNfMM UYGUlUpyKQdvPpTn
NJ16OgGooUIy6gaZuhJoQTY0EFgIrLbqyKsaxIrKrMSkKoAhFNAUUQZkTWDs SQEIYJL/BCe1JF8A
mH2qayWFFnmoBL7C0iliqDVbXkkYhAeZuB6RG0BHAqDbgFkMSICUtddOwmsG 3WayKaoTzBsAuc7S
5Gy7nxYArcEBi9uuZBI4G++/BpuVTr32nmgqosc0Mc/AByvscQXabecxxwx/ 7N9E6XRBhspliNHy
ymawLPMXjNyLQb6YACuLAqtKUNQ8IY1cAMEUSEwBxyQn0PDQ/c6Wjqo4lKqI zRfgfInOsfAsQace
yRsY0kxbEN7RTJNs8McBhHT2p1DfsMwi2V65bQBWW1Jop72NLTTRFADX0d4B ALcAx1v7y3bbNbw9
9XoXSyA1MVpTG0Jc2z18gtFPI06D/+KJUG3B4+icOkzkqfKA8gWla/4C5wt4 jjUsr79COhB8H656
DKC7Lno3u9Myu+ap384C63GbOXfd2K466fLMNx+p8DGwrjvGjQcAujCRQ6+9 C9JbHFDvs2S//fgp
dP9l9chTIn4IxVflfgvtTxB/BgDEHX/9NuTO+PfUF7O+mxuYXwrqJ0ABfs5x 8pufAVdAvP3ZA3yy
KCD+HFcoAt6PgNaboAWzNcEMehADCsQgBUmFwBBy0Ev406B6VGhA8xmqetfz Hf1O2EED2k9+1sth
BmtoQw1wEIH0o6AID6hDFAKxgkjsgAtHEEM0QTBrATTi+4JIgQrmUIpVJCEV j7hFHP+CkItFBKIO
q9jCmjkwdP2D3AxpSEYfrnCDK/ygCC0IQjrWMYFrRGL7MKhCMqZwjh2knxnP xz9uZYx8iCwfIxbY
q+Md44JwjKQkJ0nJShYPjiiw5OcsyUk7YmCJcoPhIRNJShKAkn2ONMb/SslK DZwSBOmbROxcscpW
2nJfrTsj79I4ulv6MgMNJOQDeSkMRv6SlK+009yauLNjOnMCyfQAMwH1RFjU 8pmljCamUuk/bDpT
f8JEoyFV+bJyzsxl54QZOmPGznW6U53wNGfMFhkaBzygkHSjmD41MT1uEeAq WZLfPgdqiX4u4J/o
I6hCRUUCBxAglpKY5UL1qTt7fob/mxPNaCKMSQGH5gGikZCoRnXlOYuOE5/T HCnFqGZSx2H0GM6L
qUyXp1KbebSamsKpLIKXAoIlogS52ue9WkrMgJ6UXydIgOU69i+lkSCo+mTk TUWqL53GgqcgGEDt
MiKBko0AqivlAFGtqglcGkNYxFJWAI51Aa02bABhOZtXPVE7DYC1XqMaaxVf etYJgMsn6JLM2iqw
FmohxSxydephw8aBu17rUlOtGl9pJa+HAaywhCMsTboWAK42NW2J9YBjSZoB vVI1Z2TNBBPksTSC
cRVsdV3XZuXjWYaVZDu3amw65flO3sZztzNzRPwie7PJziJB8/iZBIIG2wsU trCd/w2tukCAVW9K
gHWdu4BpLQBSSJiVFshtmtcAJzaaXDa0DsOVdV25KwsQV5AJJVTPfDaj1qKN AoX1m7pKhli9NXa9
8B3kBLYr2fgWI7wgoJxklvqC6loXu7kc8AMYsk0DEwPBiHOwNyFcqPfCyriy wHDbNIxNCBeHwPha
5jFEDDUSP9PEAfAwqUAci7vN9MY4rhaALxDDA6C4kRYeRj93HAQIK2DCL8Rn dx8xZCL/ALsy9hON
YXGpSwYyi1heAUelOUUtm4B19hzykh3x3eMC0Icz2HIH1My+K4eAcx4dckpz WtRZQNKPkHwjCj35
wRF6kIUhFKIJ9SzoE+LRzV4kgf/ULBrhJA/zqEJGc5a/mOU47lmDYLQiFaWo wClaWtB4lLQpN4HQ
RmsryMKocpd57OkrijHTYiwgrCmd6E+PMdFdFMEyPJoeXRo1n8ao0wZBPcMd 0vGNQgw1sfu8yWQj
eoSRvOKll10VPoNAAYxeXDh36dJgOxmZpda2oqf8ijx38tzorqTwMMnE9m77 12MmzrcTCeN3O7HO
IZ43Ijns63tDOtUsYDOpBF7sLgby2TCot6PFab0VB/wFBM91AjXNabe5e9yo psWW7chDHtbx4Gz0
8yZB7kdlx3rWNehxv/GE71jYrOJj/OGtsQxzTg/xfTU/4s0pDsbEXfzUSnY4 l8P/GHOaUzrnRN/0
rLFYaZRvTrgrp2bLqewmj7dR5NVGNrM5jmg+7hnPyTb2103+dHnbm+XdPrAI Iq5vRZod40GX75rT
zW4Z0P3uw075z0MZd7W3fXsKB/qjge33v0OP32eX+r/Ba3jtBZ7vg5+zK5rc eBs8HpUZt3Pl1713
42U+35tX3eVhSe7Jh170UE887FKLiT7UIRB/kAMgYv962qOht8Bt529179ve K6HzpBelSjMq59IP
P1RiNv7xB5X8zy9fV2yPNyNO+3w5NR+l1Sdo8Z2ffeZHffVT7/6erj946Yuf M9FX/ityzH6Z1vT7
dE47UjP8/hJI/lesR4WLUWAr/xGMtlXkx3Dm5wj7dznxMhTaMAj1t3DcRnjz 1yxpBS1rxSwYkCwT
6DPy0RKg9S4d8H+hkn7cNwvfchqA5SzpMlj49RiY9Vy3wjDwkoAZ4IGVEoAN eH/e0i+WhTArWFcu
El3L5RFrwzCZpYAjtX19BzlPsDFh81plw1jKki5e1RGWI4ROaFe5h3u8d4W7 h4VJIGCCJ4CjJDmB
A1igRV5Fg4KBNQFUGFuo03jgxIDwFoZco1hf04Sx5V9eAy9dpTTO4mIF6EzB BIf+5oDDcDcTkDe3
0lwW4DcGs18a8Vkb2IGNp00cMIA/tVeqNF8foGBKNQN/eEyUGEDq13qaOGKT 6P+FkAeGmbg1qvOJ
v/SGX9iAlrgAv5Nhpwg38Ccr+Wc3ytN+vjgptyhusfhrNpgJ13R6RYaKmHeE vYSMmhOKQMaM2GN3
AbRqA2RLsJiKshiGEFeNuINwgEdPqhd/hFhMxdZHE6ds1jZxhCZ2V/dnndZK 0JhiwtdNBWdsWOdJ
PdR0cYSPWMdq8qiMbjKKl3BNMldtr5aQRFRrrjZzDrmQ2SSQyhSCtJRH6bhD JUd2CBltWgdIz5Z3
pJSNnieNMuSMiBOIwziIs2hueAeSN1B39CaRUlaPamSSbTOPIESQlnCMNskD OFlgJBk+PQk1Ihl8
QdlMQ+kpKKmNcSh3SSkEP8n/XSq2ik+ZjItghOXHjVXpA1FJfZbglZXAk1up d1eZi/gXfrTke1m4
lly4hW6plm0JlysjjoKIduV4fjNolmWFiXhJWvank31ZJXpZVYgCUIE5foOJ Wogig4d5HgYQfYY5
iDbRmHrSFCTwFIM3mZQpJ3BlApjJcAuxmZVJYSPgEPgUAJ8pmmLCAJQHEINH LXihmmLyGa74KcX4
lfcADLLJJSuRAqlplz7zm7s5HNmgAtzwa4eoAM8wnMORDLfAArS4nMB5iKwQ mcyZEEbwnC2gCwZg
nYqJAY9ZCnjgndc5DgMxAGhQm6IFAOLpAOQZUWJlBHI5n1pIn2z5lvWZn/fJ JJ54oAfyqZ9jGaAC
OqAEWqAGeqAImqAKuqAM2qAO+qAQapIRAAA7
------=_NextPart_000_0017_01C31297.2788BC20--
|
|
|
| Re: Auto-sizing layouts? [message #77897 is a reply to message #77847] |
Mon, 05 May 2003 13:27 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0009_01C312F1.00014F50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
"Randy Hudson" <none@us.ibm.com> wrote in message =
news:b94mnm$j6m$1@rogue.oti.com...
> I didn't understand your original use of the word "editor". There is =
generally only a single IEditorPart. Did you mean EditPart?
Ahhh...sorry, I meant the overall application was an editor.=20
> Can you delete the "on_entry" box? Can you drag it/move it/copy it? =
If not, maybe it doesn't need to be an editpart.=20
> Just a thought. I don't know what the convention is for this type of =
application.
That's an interesting thought, since you don't move/delete those boxes =
(you could copy the contents, though) -- think of each box as a field in =
a form, albeit with some structured content. I was expecting that =
on_entry, etc. would each be an EditPart since you can edit the contents =
(add, delete, and alter commands.) At the Node level, you can alter its =
name or some other properties, but it (Node) probably doesn't need a =
full editor.
My key concern is what happens when I add a new command to a handler =
(e.g. on_entry) -- that box grows larger and the change needs to bubble =
up to the root layout: repositioning the handler's siblings, probably =
enlarging the node, and possibly nudging some other nodes. My current =
solution is to add a custom layout manager at each level except the last =
(state machine - node - handler...but not command) with:
- layout() -- call validate() and getPreferredSize() on each child; =
resize and reposition the child. Update this container's preferred size =
to match.
- getPreferredSize() -- get this container's computed preferred size.
So a call to layout() triggers validate() on each of the children, which =
recursively invokes layout() on them, updating sizes and positions after =
the child's call to layout() returns. Is this a sensible way to go?
....Richard
------=_NextPart_000_0009_01C312F1.00014F50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT face=3DArial size=3D2>"Randy Hudson" <none@us.ibm.com> =
wrote in=20
message </FONT><A href=3D"news:b94mnm$j6m$1@rogue.oti.com"><FONT =
face=3DArial=20
size=3D2>news:b94mnm$j6m$1@rogue.oti.com</FONT></A><FONT face=3DArial=20
size=3D2>...<BR><EM>> I didn't understand your original use of the =
word=20
"editor". There is generally only a single IEditorPart. Did =
you mean=20
EditPart?</EM></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ahhh...sorry, I meant the overall =
application was=20
an editor. <BR><BR><EM>> Can you delete the "on_entry" box? Can =
you=20
drag it/move it/copy it? If not, maybe it doesn't need to be an=20
editpart. </EM></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><EM>> Just a thought. I don't =
know what=20
the convention is for this type of application.</EM><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>That's an interesting thought, since =
you don't=20
move/delete those boxes (you could copy the contents, though) -- think =
of each=20
box as a field in a form, albeit with some structured content. I =
was=20
expecting that on_entry, etc. would each be an EditPart since you can =
edit the=20
contents (add, delete, and alter commands.) At the Node level, you can =
alter its=20
name or some other properties, but it (Node) probably doesn't need a =
full=20
editor.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2>My =
key concern is=20
what happens when I add a new command to a handler (e.g. on_entry) -- =
that box=20
grows larger and the change needs to bubble up to the root layout: =
repositioning=20
the handler's siblings, probably enlarging the node, and possibly =
nudging some=20
other nodes. My current solution is to add a custom layout manager at =
each level=20
except the last (state machine - node - handler...but not command)=20
with:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>- layout() -- call validate() and=20
getPreferredSize() on each child; resize and reposition the child. =
Update this=20
container's preferred size to match.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>- getPreferredSize() -- get this =
container's=20
computed preferred size.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>So a call to layout() triggers =
validate() on each=20
of the children, which recursively invokes layout() on them, updating =
sizes and=20
positions after the child's call to layout() returns. Is this a sensible =
way to=20
go?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
face=3DArial size=3D2></FONT><BR><FONT face=3DArial=20
size=3D2>...Richard</FONT></DIV></BODY></HTML>
------=_NextPart_000_0009_01C312F1.00014F50--
|
|
|
| Re: Auto-sizing layouts? [message #77917 is a reply to message #77897] |
Mon, 05 May 2003 14:15 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
This is a multi-part message in MIME format.
------=_NextPart_000_0028_01C31310.CA9A2510
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
All of this bubbling stuff is already a part of draw2d. here is a =
snippet to layout what you describe with the built-in draw2d layouts.
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.draw2d.*;
/**
* A baseclass for draw2d examples.
* @author hudsonr
*/
public class Newsgroup {
FigureCanvas fc;
IFigure contents;
Shell shell;
public static void main(String[] args) {
new Newsgroup().run();
}
protected void run(){
Display d =3D Display.getDefault();
shell =3D new Shell(d);
String appName =3D getClass().getName();
appName =3D appName.substring(appName.lastIndexOf('.')+1);
shell.setText(appName);
shell.setLayout(new GridLayout(2, false));
fc =3D new FigureCanvas(shell);
fc.setContents(contents =3D getContents());
fc.setLayoutData(new GridData(GridData.FILL_BOTH));=20
shell.pack();
shell.open();
while (!shell.isDisposed())
while (!d.readAndDispatch())
d.sleep();
}
protected IFigure getContents() {
Figure contents =3D new Figure();
ToolbarLayout layout =3D new ToolbarLayout(ToolbarLayout.HORIZONTAL);
layout.setStretchMinorAxis(true);
contents.setLayoutManager(layout);
Figure node99 =3D new Figure();
layout =3D new ToolbarLayout();
layout.setStretchMinorAxis(true);
node99.setLayoutManager(layout);
node99.setBorder(new GroupBoxBorder("Node 99"));
contents.add(node99);
=20
Label onEntry =3D new Label("set timer 1 to 24 hours");
onEntry.setBorder(new GroupBoxBorder("on_entry"));
node99.add(onEntry);
Label onIdle =3D new Label("if timeout on timer 1\n goto node100");
onIdle.setBorder(new GroupBoxBorder("on_idle"));
node99.add(onIdle);
Label onExit =3D new Label("reset timer 1");
onExit.setBorder(new GroupBoxBorder("on_exit"));
node99.add(onExit);
node99 =3D new Figure();
layout =3D new ToolbarLayout();
layout.setStretchMinorAxis(true);
node99.setLayoutManager(layout);
node99.setBorder(new GroupBoxBorder("Node 99"));
contents.add(node99);
=20
onEntry =3D new Label("return");
onEntry.setBorder(new GroupBoxBorder("on_entry"));
node99.add(onEntry);
onIdle =3D new Label("do nothing and return");
onIdle.setBorder(new GroupBoxBorder("on_idle"));
node99.add(onIdle);
onExit =3D new Label("return");
onExit.setBorder(new GroupBoxBorder("on_exit"));
node99.add(onExit);=20
return contents;
}
}
"Richard Clark" <rdclark@nextquestion.net> wrote in message =
news:b966u3$oqj$1@rogue.oti.com...
"Randy Hudson" <none@us.ibm.com> wrote in message =
news:b94mnm$j6m$1@rogue.oti.com...
> I didn't understand your original use of the word "editor". There =
is generally only a single IEditorPart. Did you mean EditPart?
Ahhh...sorry, I meant the overall application was an editor.=20
> Can you delete the "on_entry" box? Can you drag it/move it/copy it? =
If not, maybe it doesn't need to be an editpart.=20
> Just a thought. I don't know what the convention is for this type =
of application.
That's an interesting thought, since you don't move/delete those boxes =
(you could copy the contents, though) -- think of each box as a field in =
a form, albeit with some structured content. I was expecting that =
on_entry, etc. would each be an EditPart since you can edit the contents =
(add, delete, and alter commands.) At the Node level, you can alter its =
name or some other properties, but it (Node) probably doesn't need a =
full editor.
My key concern is what happens when I add a new command to a handler =
(e.g. on_entry) -- that box grows larger and the change needs to bubble =
up to the root layout: repositioning the handler's siblings, probably =
enlarging the node, and possibly nudging some other nodes. My current =
solution is to add a custom layout manager at each level except the last =
(state machine - node - handler...but not command) with:
- layout() -- call validate() and getPreferredSize() on each child; =
resize and reposition the child. Update this container's preferred size =
to match.
- getPreferredSize() -- get this container's computed preferred size.
So a call to layout() triggers validate() on each of the children, =
which recursively invokes layout() on them, updating sizes and positions =
after the child's call to layout() returns. Is this a sensible way to =
go?
...Richard
------=_NextPart_000_0028_01C31310.CA9A2510
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2723.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT face=3DArial size=3D2>All of this bubbling stuff is already a =
part of=20
draw2d. here is a snippet to layout what you describe with the =
built-in=20
draw2d layouts.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV><FONT face=3DArial =
size=3D2>
<DIV><BR>import org.eclipse.swt.layout.GridData;<BR>import=20
org.eclipse.swt.layout.GridLayout;<BR>import=20
org.eclipse.swt.widgets.Display;<BR>import =
org.eclipse.swt.widgets.Shell;</DIV>
<DIV> </DIV>
<DIV>import org.eclipse.draw2d.*;</DIV>
<DIV> </DIV>
<DIV>/**<BR> * A baseclass for draw2d examples.<BR> * @author=20
hudsonr<BR> */<BR>public class Newsgroup {</DIV>
<DIV> </DIV>
<DIV>FigureCanvas fc;<BR>IFigure contents;<BR>Shell shell;</DIV>
<DIV> </DIV>
<DIV>public static void main(String[] args) {<BR> new=20
Newsgroup().run();<BR>}</DIV>
<DIV> </DIV>
<DIV>protected void run(){<BR> Display d =3D=20
Display.getDefault();<BR> shell =3D new Shell(d);<BR> String =
appName =3D=20
getClass().getName();<BR> appName =3D=20
appName.substring(appName.lastIndexOf('.')+1);<BR> shell.setText(app=
Name);<BR> shell.setLayout(new=20
GridLayout(2, false));<BR> fc =3D new=20
FigureCanvas(shell);<BR> fc.setContents(contents =3D=20
getContents());<BR> fc.setLayoutData(new=20
GridData(GridData.FILL_BOTH)); <BR> shell.pack(); <BR> shel=
l.open();<BR> while=20
(!shell.isDisposed())<BR> while=20
(!d.readAndDispatch())<BR> d.sleep(); <BR>}</DIV>
<DIV> </DIV>
<DIV>protected IFigure getContents() {<BR> Figure contents =3D new=20
Figure();<BR> ToolbarLayout layout =3D new=20
ToolbarLayout(ToolbarLayout.HORIZONTAL);<BR> layout.setStretchMinorA=
xis(true);<BR> contents.setLayoutManager(layout); </DIV>
<DIV> </DIV>
<DIV> Figure node99 =3D new Figure();<BR> layout =3D new=20
ToolbarLayout();<BR> layout.setStretchMinorAxis(true); <BR> node=
99.setLayoutManager(layout);<BR> node99.setBorder(new=20
GroupBoxBorder("Node=20
99"));<BR> contents.add(node99);<BR> <BR> Label onEntry =
=3D new=20
Label("set timer 1 to 24 hours");<BR> onEntry.setBorder(new=20
GroupBoxBorder("on_entry"));<BR> node99.add(onEntry); </DIV>
<DIV> </DIV>
<DIV> Label onIdle =3D new Label("if timeout on timer 1\n =
goto=20
node100");<BR> onIdle.setBorder(new=20
GroupBoxBorder("on_idle"));<BR> node99.add(onIdle); </DIV>
<DIV> </DIV>
<DIV> Label onExit =3D new Label("reset timer=20
1");<BR> onExit.setBorder(new=20
GroupBoxBorder("on_exit"));<BR> node99.add(onExit); </DIV>
<DIV> </DIV>
<DIV> node99 =3D new Figure();<BR> layout =3D new=20
ToolbarLayout();<BR> layout.setStretchMinorAxis(true); <BR> node=
99.setLayoutManager(layout);<BR> node99.setBorder(new=20
GroupBoxBorder("Node=20
99"));<BR> contents.add(node99);<BR> <BR> onEntry =3D new =
Label("return");<BR> onEntry.setBorder(new=20
GroupBoxBorder("on_entry"));<BR> node99.add(onEntry); </DIV>
<DIV> </DIV>
<DIV> onIdle =3D new Label("do nothing and=20
return");<BR> onIdle.setBorder(new=20
GroupBoxBorder("on_idle"));<BR> node99.add(onIdle); </DIV>
<DIV> </DIV>
<DIV> onExit =3D new Label("return");<BR> onExit.setBorder(new =
GroupBoxBorder("on_exit"));<BR> node99.add(onExit); <BR> r=
eturn=20
contents;<BR>}</DIV>
<DIV> </DIV>
<DIV>}<BR></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Richard Clark" <<A=20
=
href=3D"mailto:rdclark@nextquestion.net">rdclark@nextquestion.net</A>>=
wrote=20
in message <A=20
=
href=3D"news:b966u3$oqj$1@rogue.oti.com">news:b966u3$oqj$1@rogue.oti.com<=
/A>...</DIV>
<DIV><FONT face=3DArial size=3D2>"Randy Hudson" <<A=20
href=3D"mailto:none@us.ibm.com">none@us.ibm.com</A>> wrote in =
message=20
</FONT><A href=3D"news:b94mnm$j6m$1@rogue.oti.com"><FONT face=3DArial=20
size=3D2>news:b94mnm$j6m$1@rogue.oti.com</FONT></A><FONT face=3DArial=20
size=3D2>...<BR><EM>> I didn't understand your original use of the =
word=20
"editor". There is generally only a single IEditorPart. =
Did you=20
mean EditPart?</EM></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ahhh...sorry, I meant the overall =
application was=20
an editor. <BR><BR><EM>> Can you delete the "on_entry" box? =
Can you=20
drag it/move it/copy it? If not, maybe it doesn't need to be an=20
editpart. </EM></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><EM>> Just a thought. I =
don't know what=20
the convention is for this type of application.</EM><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>That's an interesting thought, since =
you don't=20
move/delete those boxes (you could copy the contents, though) -- think =
of each=20
box as a field in a form, albeit with some structured content. I =
was=20
expecting that on_entry, etc. would each be an EditPart since you can =
edit the=20
contents (add, delete, and alter commands.) At the Node level, you can =
alter=20
its name or some other properties, but it (Node) probably doesn't need =
a full=20
editor.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2>My =
key concern is=20
what happens when I add a new command to a handler (e.g. on_entry) -- =
that box=20
grows larger and the change needs to bubble up to the root layout:=20
repositioning the handler's siblings, probably enlarging the node, and =
possibly nudging some other nodes. My current solution is to add a =
custom=20
layout manager at each level except the last (state machine - node -=20
handler...but not command) with:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>- layout() -- call validate() and=20
getPreferredSize() on each child; resize and reposition the child. =
Update this=20
container's preferred size to match.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>- getPreferredSize() -- get this =
container's=20
computed preferred size.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>So a call to layout() triggers =
validate() on each=20
of the children, which recursively invokes layout() on them, updating =
sizes=20
and positions after the child's call to layout() returns. Is this a =
sensible=20
way to go?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
face=3DArial size=3D2></FONT><BR><FONT face=3DArial=20
size=3D2>...Richard</FONT></DIV></BLOCKQUOTE></BODY></HTML >
------=_NextPart_000_0028_01C31310.CA9A2510--
|
|
|
Goto Forum:
Current Time: Fri May 30 16:57:39 EDT 2025
Powered by FUDForum. Page generated in 0.25018 seconds |
Home