adobe-source-devel — ASL development topic discussion

Re: [Adobe-source-devel] Code formatting

[Sean P. <sp...@ad...>]

I'm also sending this to the internal Adobe list (so for Adobe folks  
- there are external people on this list).

The tabs (with a width of 4) is a _long_ time Adobe standard but  
trying several editors it doesn't bother me either way though  
generally I prefer the notion of tabs over spaces.

If detab-ed is the general consensus then we can convert (probably  
for the next release - we should do it in one swoop).

For if statements - I'm fine with code either way - I tend to write  
single line and just set the break point in the assembly view if I  
need to break after the conditional (or loop or whatever). I'll try  
to remember to split mine up - but since that isn't just an editor  
setting I'm sure it will take awhile to train my fingers.

Sean

On Jan 19, 2006, at 2:51 PM, Thomas Witt wrote:

>
> Hi,
>
> The good news:
> 	I am not going to talk about curly braces.
>
> The bad news:
> 	I am still going to talk about code formatting.
>
>
> The following issues are things that make my life hard when dealing  
> with asl code. I bring these up because I think that there is at  
> least a chance that the potential benefits from doing it the way it  
> is done now don't outweigh the burden it puts on me and potentially  
> others working with the code.
>
> Tabs-vs-spaces:
>
> ASL code currently uses TAB's for indentation. While they might  
> work well when working only on a single project. They are a pain if  
> you work on multiple projects with different conventions at the  
> same time. It is so much easier to check whether your indentation  
> level is correct than it is to check whether you used the right  
> indentation character. I tried to do this for my asl work and I am  
> getting it wrong time and again. Other opensource projects (eg.  
> boost) have settled on spaces just because they are less brittle in  
> a multiple contributors scenario.
>
> if statements:
>
> Recently I came across a lot of one-line if statements like
>
> if (in_good_mood) do_good();
>
> there are readability arguments about code like this but this is  
> not my issue with that. My problem is that they don't allow me to  
> easily set breakpoints for the true case in Visual Studio. You can  
> only do that when do_good() is on its own line. And yes I hate to  
> format my code according to tool limitation but in the end tool  
> limitations are a fact of life and we need to get a job done.
>
> Curly braces:
>
> Just kidding ;-)
>
>
> Thanks for bearing with me. Comments?
>
> Thomas
>
> -- 
> Thomas Witt
> wi...@ac...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] Code formatting

[Thomas W. <wi...@ac...>]

Hi,

The good news:
	I am not going to talk about curly braces.

The bad news:
	I am still going to talk about code formatting.


The following issues are things that make my life hard when dealing with 
asl code. I bring these up because I think that there is at least a 
chance that the potential benefits from doing it the way it is done now 
don't outweigh the burden it puts on me and potentially others working 
with the code.

Tabs-vs-spaces:

ASL code currently uses TAB's for indentation. While they might work 
well when working only on a single project. They are a pain if you work 
on multiple projects with different conventions at the same time. It is 
so much easier to check whether your indentation level is correct than 
it is to check whether you used the right indentation character. I tried 
to do this for my asl work and I am getting it wrong time and again. 
Other opensource projects (eg. boost) have settled on spaces just 
because they are less brittle in a multiple contributors scenario.

if statements:

Recently I came across a lot of one-line if statements like

if (in_good_mood) do_good();

there are readability arguments about code like this but this is not my 
issue with that. My problem is that they don't allow me to easily set 
breakpoints for the true case in Visual Studio. You can only do that 
when do_good() is on its own line. And yes I hate to format my code 
according to tool limitation but in the end tool limitations are a fact 
of life and we need to get a job done.

Curly braces:

Just kidding ;-)


Thanks for bearing with me. Comments?

Thomas

-- 
Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] win32 group_window_proc

[Thomas W. <wi...@ac...>]

Mat,

DISCLAIMER: I am not an win32 gui expert and I've been known to be wrong 
in the past.

Mat Marcus wrote:
>  
> 
> I added the group windowproc. Before I did we were noticing that buttons and
> sliders were not working when contained in a group. IIRC, after playing
> around with Spy++ it seemed to be that notifications were not making it far
> enough up the containment hierarchy--they were getting stopped at the group.

I did some reading in the MSDN documentation about WM_COMMAND. 
WM_COMMAND messages are always send to the parent of the widget 
generating the command message. The rationale behind this is to make 
certain idioms easier. E.g. in a dialog the button clicked command can 
directly handled in the dialog code without doing anything in the button 
code. Whether this is a good idea I can't say but it sure does not fit 
the composition approach used for eve widgets where each widget reports 
its own state changes.

Given this I think that every potential parent widget should forward 
WM_COMMAND to its children. In our case these are dialog/panels/groups 
and whatever I missed.

> When I added the group window proc to propagate messages upwards, things
> began to work inside groups for the first time. Command notifications were
> making it as far as the panel or dlog window_proc, from which
> forward_events_to_control is called.

This kind of works but seems to be an unnecessary twisted way of message 
routing. The reason it only kind of works is that not all command 
messages are forwarded. Those for combo boxes aren't.

> 
> Doesn't passing the WM_COMMANDs to parents cause the notification to go to
> panel_window_proc from which forward_events_to_control will be called? 

Yep but see above.

> 
>> Did I miss something?
> 
> I'm not an expert in this area so I couldn't say. Maybe there's a better way
> to go. Do you have further thoughts?

I am mildly confident that passing them to children directly is the 
right way to go.

Thomas

-- 
Thomas Witt
wi...@ac...

RE: [Adobe-source-devel] win32 group_window_proc

[Mat M. <mm...@em...>]

 

> -----Original Message-----
> From: ado...@li... 
> [mailto:ado...@li...] On 
> Behalf Of Thomas Witt
> Sent: Wednesday, January 18, 2006 9:56 PM
> To: ado...@li...
> Subject: [Adobe-source-devel] win32 group_window_proc
> 
> 
> Hi,
> 
> currently the command routing for direct child widgets of a 
> group is broken. One way to demonstrate is to put a popup in 
> a group. Changes made to the selection will not propagate to 
> adam due to the popup not getting the CBN_SELCHANGE 
> WM_COMMAND message. Put a brakepoint in 
> popup_t::implementation_t::event to see what I am talking about.
> 
> The culprit seems to be group_window_proc the comment 
> preceding its definition says:
> 
> "Groups don't forward WM_COMMANDS to their parents by 
> default. We trap the windowproc here to do so."

I added the group windowproc. Before I did we were noticing that buttons and
sliders were not working when contained in a group. IIRC, after playing
around with Spy++ it seemed to be that notifications were not making it far
enough up the containment hierarchy--they were getting stopped at the group.
When I added the group window proc to propagate messages upwards, things
began to work inside groups for the first time. Command notifications were
making it as far as the panel or dlog window_proc, from which
forward_events_to_control is called.

> This leaves me wondering why WM_COMMANDS should go to 
> parents. AFAICS they should be forwarded to children in the 
> same way it is done in the panel_window_proc. Adding a call 
> to forward_events_to_control to group_window_proc seems to 
> solve the issues with popups and cause no problems.

Doesn't passing the WM_COMMANDs to parents cause the notification to go to
panel_window_proc from which forward_events_to_control will be called? 

> Did I miss something?

I'm not an expert in this area so I couldn't say. Maybe there's a better way
to go. Do you have further thoughts?

> Thomas

 - Mat

[Adobe-source-devel] win32 group_window_proc

[Thomas W. <wi...@ac...>]

Hi,

currently the command routing for direct child widgets of a group is 
broken. One way to demonstrate is to put a popup in a group. Changes 
made to the selection will not propagate to adam due to the popup not 
getting the CBN_SELCHANGE WM_COMMAND message. Put a brakepoint in 
popup_t::implementation_t::event to see what I am talking about.

The culprit seems to be group_window_proc the comment preceding its 
definition says:

"Groups don't forward WM_COMMANDS to their parents by default. We trap 
the windowproc here to do so."

This leaves me wondering why WM_COMMANDS should go to parents. AFAICS 
they should be forwarded to children in the same way it is done in the 
panel_window_proc. Adding a call to forward_events_to_control to 
group_window_proc seems to solve the issues with popups and cause no 
problems.

Did I miss something?

Thomas

-- 
Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] edit_number win32

[Sean P. <sp...@ad...>]

On Jan 18, 2006, at 3:16 PM, Thomas Witt wrote:

> Sean Parent wrote:
>> On Jan 17, 2006, at 6:35 PM, Thomas Witt wrote:
>>> the attached patch fixes a edit_number layout issue in the win32  
>>> implementation. In more complex layouts the popup is not  
>>> displayed correctly because eve adjusts the poi that is used to  
>>> store the popup position but not the the overall widget length. I  
>>> am not sure whether this might actually be an eve issue, but the  
>>> patch makes edit_number work and brings its logic in line with  
>>> the Mac implementation that does not use a poi for this AFAICS.
>> For leaf nodes Eve moves the widget for the first poi (and adjusts  
>> the width after that) - for an edit_number, the widget shouldn't  
>> be stretching since there is just a single poi.
>
> This is true for Mac afaics. The win32 implementation stores a  
> second horizontal poi at the popup widget position and that does   
> not work.

I'll take a look at your example - two issues here...

Windows should be consistent with Mac - (one poi is sufficient - at  
least until I get named poi's implemented).

With two pois the behavior should be to offset to align the first  
poi, and stretch to align the second. I'll have to check the code...

Thanks!
Sean

>
>> Can you send an example?
>
> See attached sheets. The edit_numbers in the "Analysis" group  
> should show the problem.
>
> Thomas
>
> -- 
> Thomas Witt
> wi...@ac...
> /*
> 	Copyright 2005 Zephyr Assoc. Inc.
> */
>
>
>
> sheet parameter
>
> {
> constant:
> 	most_recent_units_monthly: [ {name: "Years", bind: @last_years},  
> {name: "Quarters", bind: @last_quarters}, {name: "Months", bind:  
> @last_months} ];
> 	most_recent_units_quarterly: [ {name: "Years", bind: @last_years},  
> {name: "Quarters", bind: @last_quarters} ];
>
> interface:
> 	periodicity: @monthly;
>
> 	most_recent_units: most_recent_units_monthly <== (periodicity ==  
> @monthly) ? most_recent_units_monthly : most_recent_units_quarterly;
>
> 	use_latest: @period;
>
> 	last_years : 5;
> 	last_quarters : 5;
> 	last_months : 12;
>
> 	recent_period_unit: 5;
>
> 	period_spec: @range;
> 	constraint_spec: @long;
>
> }
>
> /*
> 	Copyright 2005 Zephyr Assoc. Inc.; All Rights Reserved.
> */
>
> dialog(name: "Parameter", placement: place_column, grow: true)
> {
> 	row()
> 	{
>
> 		column()
> 		{
>
> 			group (name: "Analysis")
> 			{
>
> 				row(child_horizontal: align_left, horizontal: align_fill)
> 				{
> 					popup(name: "Periodicity", bind: @periodicity, items: [ {name:  
> "Quarterly", value: @quarterly}, {name: "Monthly", value:  
> @monthly} ]);
> 				}
>
>
> 				row()
> 				{
> 					radio_button( name: "", bind: @period_spec, value: @range );
> 					popup(name: "From", items: [  {name: "01/01/1979", value: 1},  
> {name: "11/30/2005", value: 2} ]);
> 					popup(name: "To", items: [  {name: "01/01/1979", value: 1},  
> {name: "11/30/2005", value: 2} ]);
> 				}
>
>
> 				row( guide_mask: [ @guide_label ] )
> 				{
> 					radio_button( name: "Use latest", bind: @period_spec, value:  
> @latest );
>
> 					column()
> 					{
>
> 					edit_number( name: "edit_number", horizontal: align_left,  
> units: [ {name: "Years", bind: @last_years}, {name: "Quarters",  
> bind: @last_quarters}, {name: "Months", bind: @last_months} ] );
>
> 					popup ( name: "ending",
> 					             bind: @use_latest,
> 					             items: [
> 						{name: "most recent period", value: @most_recent_period},
> 						{name: "most recent quarter", value: @most_recent_quarter},
> 						{name: "most recent calendar year", value:  
> @most_recent_calendar_year},
> 						{name: "most recent fiscal year", value:  
> @most_recent_fiscal_year},
> 						{name: "a period of time ago", value: @period},
> 						{name: "on a specific date", value: @specific_date} ] );
>
> 					row()
> 					{
> 					overlay()
> 					{
> 						panel( bind: @use_latest, value: @period )
> 						{
> 							edit_number(name: "Ends:", units: [ {name: "Years", bind:  
> @last_years}, {name: "Quarters", bind: @last_quarters}, {name:  
> "Months", bind: @last_months} ]);
> 						}
>
> 						panel( bind: @use_latest, value: @specific_date )
> 						{
> 							popup(name: "To", items: [  {name: "01/01/1979", value: 1},  
> {name: "11/30/2005", value: 2} ]);
> 						}
> 					}
> 					}
> 					}
> 				}
>
> 				checkbox( name: "Don't limit dates to common periods.", value:  
> 1 );
>
> 			}
>
>
> 			group ( name: "Computation", horizontal: align_fill, guide_mask:  
> [ @guide_label ] )
> 			{
> 				edit_number( name: "Trailing window size (Months):" );
> 				popup(name: "Move computation window", items: [  {name:  
> "Monthly", value: @monthly}, {name: "Quarterly", value:  
> @quarterly},  {name: "Annually", value: @annually} ]);
> 				popup(name: "Performance", items: [ {name: "In-Sample", value:  
> 1}, {name: "Out-of-sample", value: 2} ]);
> 				edit_number( name: "Number of computation points:" );
> 			}
>
> 			popup(name: "Currency", items: [ {name: "US-Dollar (USD)",  
> value: @usd}, {name: "Euro (EUR)", value: @eur} ]);
>
> 		}
>
>
> 		column()
> 		{
> 			group ( name: "Constraints" )
> 			{
> 				radio_button( name: "Long only", bind: @constraint_spec, value:  
> @long );
> 				row()
> 				{
> 					radio_button( name: "Max % in short", bind: @constraint_spec,  
> value: @short );
> 				}
> 			}
> 		}
>
> 	}
>
> 	separator();
>
>
> 	row(child_horizontal: align_right, horizontal: align_fill)
> 	{
>
> 		button(name: "Ok", default: true, action: @ok, horizontal:  
> align_right);
> 		button(name: "Cancel", action: @cancel, horizontal: align_right);
> 	}
>
> }

Re: [Adobe-source-devel] edit_number win32

[Thomas W. <wi...@ac...>]

Sean Parent wrote:
> 
> On Jan 17, 2006, at 6:35 PM, Thomas Witt wrote:
> 
>> the attached patch fixes a edit_number layout issue in the win32 
>> implementation. In more complex layouts the popup is not displayed 
>> correctly because eve adjusts the poi that is used to store the popup 
>> position but not the the overall widget length. I am not sure whether 
>> this might actually be an eve issue, but the patch makes edit_number 
>> work and brings its logic in line with the Mac implementation that 
>> does not use a poi for this AFAICS.
> 
> 
> For leaf nodes Eve moves the widget for the first poi (and adjusts the 
> width after that) - for an edit_number, the widget shouldn't be 
> stretching since there is just a single poi.

This is true for Mac afaics. The win32 implementation stores a second 
horizontal poi at the popup widget position and that does  not work.

> Can you send an example?

See attached sheets. The edit_numbers in the "Analysis" group should 
show the problem.

Thomas

-- 
Thomas Witt
wi...@ac...

[Adobe-source-devel] edit_number win32

[Thomas W. <wi...@ac...>]

Hi,

the attached patch fixes a edit_number layout issue in the win32 
implementation. In more complex layouts the popup is not displayed 
correctly because eve adjusts the poi that is used to store the popup 
position but not the the overall widget length. I am not sure whether 
this might actually be an eve issue, but the patch makes edit_number 
work and brings its logic in line with the Mac implementation that does 
not use a poi for this AFAICS.

Regards

Thomas

-- 
Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] edit_number crash

[Ralph T. <ra...@gm...>]

Unfortunately the edit_... proxies still exist in my tree[1], but I
hope to finish removing them before the month is over. Currently my
client_assembler also has some extra code in that allows me to bind
widgets to things outside of Adam[2] so it's not a drop-in
replacement, but it shouldn't be too much work to change it to just
use Adam.

Ralph

[1] my client_assembler is here:
http://www.missioncode.org/index.fcgi/browser/external/adobe/future/widgets=
/sources/client_assembler.cpp

On 1/12/06, Foster T. Brereton <fbr...@ad...> wrote:
> Hi Thomas,
>
> The answer to the fix is twofold. The first answer is that if the
> control isn't bound to any cell, it should just break out of this
> function prematurely. The existence of
> edit_number_proxy_t::control_value is explicitly for the propagation
> of the user value to Adam. So in the case the control isn't bound to
> Adam, control_value isn't necessary. The second answer is that the
> edit_number_proxy_t class as a whole need not exist. We made a push a
> while back to eliminate all the proxy code from client_assembler, and
> in its place have generic propagation functions to communicate values
> in between the various application components. We put it on the back
> burner as other priorities came up. It's a more complicated fix, but
> is the direction the code should be headed. If I understand
> correctly, Ralph Thomas has a local version of ASL 1.0.12 that, among
> other things, has the proxy code all but eliminated.
>
> Blessings,
> Foster
>
>
> On Jan 12, 2006, at 10:40a, Thomas Witt wrote:
>
> >
> > Hi,
> >
> > edit_number_proxy_t currently does not handle edit_number widgets
> > that are not bound to an adam cell. The reason for this is that
> > edit_number_proxy_t::control_value tries to write ot the values_m
> > array that was never setup (usually this is done in monitor_value).
> >
> > The question is: what is the right fix? Make edit_number_proxy_t
> > handle this case or change the parser code to require a bind field.
> >
> > Regards
> >
> > Thomas
> >
> > --
> > Thomas Witt
> > wi...@ac...
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through
> > log files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD
> > SPLUNK!
> > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > Adobe-source-devel mailing list
> > Ado...@li...
> > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
> --
> Foster T. Brereton              <}}}><              Romans 3:21-26
> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
> "The fact is that the author of STL does not know how to write min,
> the author of C++ is not quite sure, and the standards committee is
> at a loss." -- Alexander Stepanov
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

Re: [Adobe-source-devel] edit_number crash

[Foster T. B. <fbr...@ad...>]

Hi Thomas,

The answer to the fix is twofold. The first answer is that if the  
control isn't bound to any cell, it should just break out of this  
function prematurely. The existence of  
edit_number_proxy_t::control_value is explicitly for the propagation  
of the user value to Adam. So in the case the control isn't bound to  
Adam, control_value isn't necessary. The second answer is that the  
edit_number_proxy_t class as a whole need not exist. We made a push a  
while back to eliminate all the proxy code from client_assembler, and  
in its place have generic propagation functions to communicate values  
in between the various application components. We put it on the back  
burner as other priorities came up. It's a more complicated fix, but  
is the direction the code should be headed. If I understand  
correctly, Ralph Thomas has a local version of ASL 1.0.12 that, among  
other things, has the proxy code all but eliminated.

Blessings,
Foster


On Jan 12, 2006, at 10:40a, Thomas Witt wrote:

>
> Hi,
>
> edit_number_proxy_t currently does not handle edit_number widgets  
> that are not bound to an adam cell. The reason for this is that  
> edit_number_proxy_t::control_value tries to write ot the values_m  
> array that was never setup (usually this is done in monitor_value).
>
> The question is: what is the right fix? Make edit_number_proxy_t  
> handle this case or change the parser code to require a bind field.
>
> Regards
>
> Thomas
>
> -- 
> Thomas Witt
> wi...@ac...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"The fact is that the author of STL does not know how to write min,  
the author of C++ is not quite sure, and the standards committee is  
at a loss." -- Alexander Stepanov

[Adobe-source-devel] edit_number crash

[Thomas W. <wi...@ac...>]

Hi,

edit_number_proxy_t currently does not handle edit_number widgets that 
are not bound to an adam cell. The reason for this is that 
edit_number_proxy_t::control_value tries to write ot the values_m array 
that was never setup (usually this is done in monitor_value).

The question is: what is the right fix? Make edit_number_proxy_t handle 
this case or change the parser code to require a bind field.

Regards

Thomas

-- 
Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] Custom layouts

[Sean P. <sea...@ma...>]

I see three things here of interest -

1. Support for custom containers in Eve (been on my to-do list for  
awhile) -
2. Support for a "flow" container, and/or grid container, and/or flow  
support for rows/columns.
3. A specific custom icon view grid view to go with 1.

So yep - we're interested.
Sean

On Jan 6, 2006, at 10:18 AM, Ralph Thomas wrote:

> Hi Adobe-source,
>
>   I needed to make an icon view for my toy photo program [1], and I
> ended up adding support to Eve such that containers can adjust child
> locations once Eve has performed all of it's evaluate/adjust code. I
> wrote a custom container which tells Eve it's an overlay, but adjusts
> all of the child locations so that the children appear in a grid.
>
>   Would there be any interest in including this in ASL (perhaps as a
> test or in future) if I ported it to 1.0.12?
>
> Ralph
>
> [1]: http://www.missioncode.org/index.fcgi/wiki/PhotoOrganizer
> Diff against Eve: http://www.missioncode.org/index.fcgi/changeset/10
> Sample table layout:
> http://www.missioncode.org/index.fcgi/browser/view/generic/table.c% 
> 2B%2B?rev=10
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] Re: Custom layouts

[Ralph T. <ra...@gm...>]

Sorry, I actually have a better table implementation:

  http://www.missioncode.org/index.fcgi/browser/view/generic/table.c%2B%2B?=
rev=3D11

I thought that it looked a bit different!

Ralph

On 1/6/06, Ralph Thomas <ra...@gm...> wrote:
> Hi Adobe-source,
>
>   I needed to make an icon view for my toy photo program [1], and I
> ended up adding support to Eve such that containers can adjust child
> locations once Eve has performed all of it's evaluate/adjust code. I
> wrote a custom container which tells Eve it's an overlay, but adjusts
> all of the child locations so that the children appear in a grid.
>
>   Would there be any interest in including this in ASL (perhaps as a
> test or in future) if I ported it to 1.0.12?
>
> Ralph
>
> [1]: http://www.missioncode.org/index.fcgi/wiki/PhotoOrganizer
> Diff against Eve: http://www.missioncode.org/index.fcgi/changeset/10
> Sample table layout:
> http://www.missioncode.org/index.fcgi/browser/view/generic/table.c%2B%2B?=
rev=3D10
>

[Adobe-source-devel] Custom layouts

[Ralph T. <ra...@gm...>]

Hi Adobe-source,

  I needed to make an icon view for my toy photo program [1], and I
ended up adding support to Eve such that containers can adjust child
locations once Eve has performed all of it's evaluate/adjust code. I
wrote a custom container which tells Eve it's an overlay, but adjusts
all of the child locations so that the children appear in a grid.

  Would there be any interest in including this in ASL (perhaps as a
test or in future) if I ported it to 1.0.12?

Ralph

[1]: http://www.missioncode.org/index.fcgi/wiki/PhotoOrganizer
Diff against Eve: http://www.missioncode.org/index.fcgi/changeset/10
Sample table layout:
http://www.missioncode.org/index.fcgi/browser/view/generic/table.c%2B%2B?re=
v=3D10

Re: [Adobe-source-devel] group nesting issues windows

[Ralph T. <ra...@gm...>]

This kind of thing:

group() { panel() { static_text( name: "blah" ); } }

now works well, but this kind of thing:

tab_group() { panel() { panel() { static_text( name: "blah" ); } } }

shows grey behind the static text widget (instead of the tab group
texture, which is a subtle white-grey gradient on the default Windows
XP visual style). This bug was present in previous versions of ASL too
though, so there is no regression. I'll try to work on a fix tonight.

There is also a bug that Foster mentioned where a button inside a
group has a mysterious border around it. I investigated that last
night but haven't found out why yet (it might be the way that the
parent button [the group] handles the WM_CTLCOLORBUTTON message, but
I'm not sure).

Ralph

On 1/5/06, Mat Marcus <mm...@em...> wrote:
> > -----Original Message-----
> > From: ado...@li...
> > [mailto:ado...@li...] On
> > Behalf Of Steve Tibbett
> > Sent: Thursday, January 05, 2006 5:07 AM
> > To: Thomas Witt; Mat Marcus
> > Cc: ado...@li...
> > Subject: RE: [Adobe-source-devel] group nesting issues windows
> >
> > > As a result, I am working with the idea that the text is getting
> > > drawn, but something additional is getting drawn/erased and
> > obscuring
> > > the text  in the group case.
> >
> > I'm guessing what you're seeing is the group box painting
> > itself after the button has been painted and since the group
> > box's extent covers the button, it would be erasing it.
> >
> > Controls are painted in the order they're created I believe,
> > but this is also controlled by the WS_CLIPSIBLINGS window
> > style.  If this isn't set, then one button can paint over
> > another one that's on top of it - it's an optimization thing.
> >  Perhaps setting this style will prevent what you're seeing.
>
> Thanks for the suggestion Steve. I read up on that option and explored su=
ch
> solutions for a while. In this case the issues turned out to be with the
> panel windowproc. Ralph Thomas stepped in at the 11th hour and came up wi=
th
> a patch to clear up the main issues that Thomas Witt identified. While so=
me
> additional Win32 bugs remain to be cleared up, Release 1.0.12 should allo=
w
> him to make more progress. Please let us know.
>
>  - Mat
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

RE: [Adobe-source-devel] group nesting issues windows

[Mat M. <mm...@em...>]

> -----Original Message-----
> From: ado...@li... 
> [mailto:ado...@li...] On 
> Behalf Of Steve Tibbett
> Sent: Thursday, January 05, 2006 5:07 AM
> To: Thomas Witt; Mat Marcus
> Cc: ado...@li...
> Subject: RE: [Adobe-source-devel] group nesting issues windows
> 
> > As a result, I am working with the idea that the text is getting 
> > drawn, but something additional is getting drawn/erased and 
> obscuring 
> > the text  in the group case.
> 
> I'm guessing what you're seeing is the group box painting 
> itself after the button has been painted and since the group 
> box's extent covers the button, it would be erasing it.
> 
> Controls are painted in the order they're created I believe, 
> but this is also controlled by the WS_CLIPSIBLINGS window 
> style.  If this isn't set, then one button can paint over 
> another one that's on top of it - it's an optimization thing. 
>  Perhaps setting this style will prevent what you're seeing.

Thanks for the suggestion Steve. I read up on that option and explored such
solutions for a while. In this case the issues turned out to be with the
panel windowproc. Ralph Thomas stepped in at the 11th hour and came up with
a patch to clear up the main issues that Thomas Witt identified. While some
additional Win32 bugs remain to be cleared up, Release 1.0.12 should allow
him to make more progress. Please let us know.

 - Mat

Re: [Adobe-source-devel] group nesting issues windows

[Thomas W. <wi...@ac...>]

On Jan 5, 2006, at 1:37 PM, Thomas Witt wrote:

> Hmm=85 there is another option: The static text does not draw its =20
> background correctly. Interestingly nesting another panel in the =20
> panel that's already there will make the static text paint correctly.

Here is another interesting experiment: Nest the nested group box =20
"Bar" in a panel.

;-)



Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] Widget attributes referencing adam cells

[Thomas W. <wi...@ac...>]

On Jan 4, 2006, at 2:57 PM, Sean Parent wrote:

> Attribute bindings are currently unimplemented - now that it's  
> possible to force a full re-layout (done for hide/show which isn't  
> quite finished yet) - it should be possible to wire up indirect  
> attributes.

That would be cool. My current use case are edit_number widgets where  
the choice of units depends on the selection in some other input  
field. I guess the only way to do this currently are overlays?

Thomas



Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] group nesting issues windows

[Thomas W. <wi...@ac...>]

Mat,

On Jan 4, 2006, at 6:08 PM, Mat Marcus wrote:

> I ran Begin with your group.* files and with a modified version =20
> that set
> Overlay to a row instead of a group. Drawing worked fine in the =20
> latter but
> as you point out, a black box is drawn in the first case. =20
> Interestingly, a
> Spy++ capture shows WM_GETTEXT and WM_PAINT messages in each case. =20
> As a
> result, I am working with the idea that the text is getting drawn, but
> something additional is getting drawn/erased and obscuring the text =20=

> in the
> group case.

Hmm=85 there is another option: The static text does not draw its =20
background correctly. Interestingly nesting another panel in the =20
panel that's already there will make the static text paint correctly.

No idea what to make of this.

Thomas


Thomas Witt
wi...@ac...

RE: [Adobe-source-devel] group nesting issues windows

[Steve T. <sti...@ad...>]

> As a result, I am working with the idea that the text is getting=20
> drawn, but something additional is getting drawn/erased and obscuring=20
> the text  in the group case.=20

I'm guessing what you're seeing is the group box painting itself after
the button has been painted and since the group box's extent covers the
button, it would be erasing it.

Controls are painted in the order they're created I believe, but this is
also controlled by the WS_CLIPSIBLINGS window style.  If this isn't set,
then one button can paint over another one that's on top of it - it's an
optimization thing.  Perhaps setting this style will prevent what you're
seeing.

--
Steve Tibbett
sti...@ad...

Re: [Adobe-source-devel] group nesting issues windows

[Thomas W. <wi...@ac...>]

Hi Mat,

On Jan 4, 2006, at 6:08 PM, Mat Marcus wrote:

>
> I spent a bit of time looking into this today to see if I could fix  
> it for
> the the upcoming release.

Thanks!

> The presence of the overlay group is definitely
> interfering with the proper drawing of the panel/static-text. As you
> probably know, groups are implemented as buttons in the Win32 API.

Yep, seems natural doesn't it?

>
> I ran Begin with your group.* files and with a modified version  
> that set
> Overlay to a row instead of a group. Drawing worked fine in the  
> latter but
> as you point out, a black box is drawn in the first case.  
> Interestingly, a
> Spy++ capture shows WM_GETTEXT and WM_PAINT messages in each case.  
> As a
> result, I am working with the idea that the text is getting drawn, but
> something additional is getting drawn/erased and obscuring the text  
> in the
> group case. I am just coming up to speed on Win32 API programming,  
> so I
> welcome any suggestions at this point.

I have to admit I am at a loss here. So far the Win32 API has  
withstood all my attempts to approach it using logic and inference.  
It seems the only way to make sense of it is to memorize an infinite  
number of idiosyncrasies. Unfortunately I am not really good at that.

Thomas

Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] group nesting issues windows

[Sean P. <sp...@ad...>]

I'm not that familiar with the Win32 API but is this a necessity? How  
are groups normally handled on Win32? There isn't any Eve requirement  
that they look similar to the Mac implementation or anything - we  
should do them however they are normally done on Windows.
On Jan 4, 2006, at 6:08 PM, Mat Marcus wrote:

> As you
> probably know, groups are implemented as buttons in the Win32 API.

RE: [Adobe-source-devel] group nesting issues windows

[Mat M. <mm...@em...>]

 

> -----Original Message-----
> From: ado...@li... 
> [mailto:ado...@li...] On 
> Behalf Of Thomas Witt
> Sent: Tuesday, January 03, 2006 8:46 PM
> To: ado...@li...
> Subject: [Adobe-source-devel] group nesting issues windows
> 
> 
> Hi,
> 
> attached are sheets that demonstrate what I think are nesting 
> issues with the group widget on Windows. On Windows XP the 
> nested group uses a bigger font for the group name and the 
> overlay displays as one black block.

Hi Thomas,

I spent a bit of time looking into this today to see if I could fix it for
the the upcoming release. The presence of the overlay group is definitely
interfering with the proper drawing of the panel/static-text. As you
probably know, groups are implemented as buttons in the Win32 API. Worse
yet, groups seem to prevent messages from being passed between
child<->parent. In the last release I trapped the group window_proc to
propagate messages, but perhaps I didn't go far enough?

I ran Begin with your group.* files and with a modified version that set
Overlay to a row instead of a group. Drawing worked fine in the latter but
as you point out, a black box is drawn in the first case. Interestingly, a
Spy++ capture shows WM_GETTEXT and WM_PAINT messages in each case. As a
result, I am working with the idea that the text is getting drawn, but
something additional is getting drawn/erased and obscuring the text in the
group case. I am just coming up to speed on Win32 API programming, so I
welcome any suggestions at this point.

 - Mat

Re: [Adobe-source-devel] Widget attributes referencing adam cells

[Sean P. <sp...@ad...>]

Attribute bindings are currently unimplemented - now that it's  
possible to force a full re-layout (done for hide/show which isn't  
quite finished yet) - it should be possible to wire up indirect  
attributes.

Sean

On Jan 4, 2006, at 2:38 PM, Thomas Witt wrote:

>
> Hi,
>
> If I am reading the documentation correctly it should be possible  
> for widget attributes to reference adam cells. I just can't make it  
> work. Attached is an example of what I am trying to do. Any help  
> would be greatly appreciated.
>
> Regards
>
> Thomas
>
> Thomas Witt
> wi...@ac...
>
> <sheet_ref.adm>
> <sheet_ref.eve>

[Adobe-source-devel] Widget attributes referencing adam cells

[Thomas W. <wi...@ac...>]

Hi,

If I am reading the documentation correctly it should be possible for  
widget attributes to reference adam cells. I just can't make it work.  
Attached is an example of what I am trying to do. Any help would be  
greatly appreciated.

Regards

Thomas

Thomas Witt
wi...@ac...