headers
Max Carlson | 1 Nov 01:47
Favicon

For Review: Change 20061031-maxcarlson-o Summary: UPDATED: Fix enter key in multiline inputtext, fix multiline text, add password input type, all text metrics identical in swf and dhtml

Change 20061031-maxcarlson-o by maxcarlson <at> max-carlsons- 
computer.local on 2006-10-31 16:39:19 PST
     in /Users/maxcarlson/openlaszlo/legals

Summary: UPDATED: Fix enter key in multiline inputtext, fix multiline  
text, add password input type, all text metrics identical in swf and  
dhtml

New Features:

Bugs Fixed: LPP-2900 - Don't snarf enter (and other keys) when  
editing an inputtext

Technical Reviewer: hqm
QA Reviewer: ptw
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details: Fixed enter key in multiline inputtext, fix regression in  
multiline text, add password field, added setMaxLength() to DHTML,   
metrics test /legals/test/lztest/lztest-textheight.lzx passes in both  
swf and dhtml (except for one dhtml exception) and are visually  
identical.

Tests: Comparing /legals/test/lztest/lztest-textheight.lzx?lzr=dhtml
(Continue reading)

Permalink | Reply | 0 comments |
headers
Max Carlson | 1 Nov 02:27
Favicon

For Review: Change 20061031-maxcarlson-l Summary: UPDATED: Fix enter key in multiline inputtext, fix multiline text, add password input type, all text metrics identical in swf and dhtml

Change 20061031-maxcarlson-l by maxcarlson <at> max-carlsons- 
computer.local on 2006-10-31 17:20:20 PST
     in /Users/maxcarlson/openlaszlo/legals

Summary: UPDATED (for the last time): Fix enter key in multiline  
inputtext, fix multiline text, add password input type, all text  
metrics identical in swf and dhtml

New Features:

Bugs Fixed: LPP-2900 - Don't snarf enter (and other keys) when  
editing an inputtext

Technical Reviewer: hqm
QA Reviewer: ptw
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details: Fixed enter key in multiline inputtext, fix regression in  
multiline text, add password field, added setMaxLength() to DHTML,   
metrics test legals/test/lztest/lztest-textheight.lzx passes in both  
swf and dhtml and are visually identical.

Tests: Comparing legals/test/lztest/lztest-textheight.lzx? 
lzr=dhtml&debug=true vs legals/test/lztest/lztest-textheight.lzx? 
lzr=swf7&debug=true should pass in swf and dhtml and should be  
visually identical.  also, legals/examples/components/
(Continue reading)

Permalink | Reply | 4 comments |
headers
Philip Romanik | 1 Nov 03:36
Favicon

LzNode.determinePlacement

Hi Tucker,

determinePlacement() has 3 arguments but most components only mention the 
first two (basetabs.lzx for example) when overridden. This is a bit of a 
nit, but I think all references to super.determinePlacement() should pass 
all 3 parameters. Or, is the third parameter cruft?

Thanks!

Phil
Permalink | Reply | 9 comments |
headers
Jim Grandy | 1 Nov 06:13
Favicon

For Review: Change 20061031-jgrandyw-8 Summary: Temporarily disable cross-ref support in Legals devguide to get it compiling

Change 20061031-jgrandyw-8 by jgrandyw <at> jgrandy-pb.local on 2006-10-31  
13:42:09 PST
     in /Volumes/data/Users/jgrandyw/dev/svn/openlaszlo/branches/legals

Summary: Temporarily disable cross-ref support in Legals devguide to  
get it compiling

Bugs Fixed:LPP-2994

Technical Reviewer: bshine
QA Reviewer:
Doc Reviewer:

Details:The DevGuide depends on a working refguide build in order to
insert cross references. By turning off cross-reference support, we can
get the DevGuide working in advance of the RefGuide being updated.

Tests:

Files:
M      docs/src/build.xml
M      docs/src/xsl/xref.xsl
M      build.xml

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20061031- 
jgrandyw-8.tar
Permalink | Reply | 0 comments |
headers
P T Withington | 1 Nov 11:58
Favicon

Re: For Review: Change 20061031-maxcarlson-l Summary: UPDATED: Fix enter key in multiline inputtext, fix multiline text, add password input type, all text metrics identical in swf and dhtml

Hey Max, can you make sure your svn-bash is up to date?  You are not  
sending along the change package reference with these messages, so we  
can't review.

On 2006-10-31, at 20:27 EST, Max Carlson wrote:

> Change 20061031-maxcarlson-l by maxcarlson <at> max-carlsons- 
> computer.local on 2006-10-31 17:20:20 PST
>     in /Users/maxcarlson/openlaszlo/legals
>
> Summary: UPDATED (for the last time): Fix enter key in multiline  
> inputtext, fix multiline text, add password input type, all text  
> metrics identical in swf and dhtml
>
> New Features:
>
> Bugs Fixed: LPP-2900 - Don't snarf enter (and other keys) when  
> editing an inputtext
>
> Technical Reviewer: hqm
> QA Reviewer: ptw
> Doc Reviewer: (pending)
>
> Documentation:
>
> Release Notes:
>
> Details: Fixed enter key in multiline inputtext, fix regression in  
> multiline text, add password field, added setMaxLength() to DHTML,   
> metrics test legals/test/lztest/lztest-textheight.lzx passes in
(Continue reading)

Permalink | Reply | 3 comments |
headers
P T Withington | 1 Nov 15:36
Favicon

Re: LzNode.determinePlacement

I agree.  When calling your super method, you should pass all the  
arguments that you are called with.

On 2006-10-31, at 21:36 EST, Philip Romanik wrote:

> Hi Tucker,
>
> determinePlacement() has 3 arguments but most components only  
> mention the first two (basetabs.lzx for example) when overridden.  
> This is a bit of a nit, but I think all references to  
> super.determinePlacement() should pass all 3 parameters. Or, is the  
> third parameter cruft?
>
> Thanks!
>
> Phil
>
Permalink | Reply | 8 comments |
headers
Jim Grandy | 1 Nov 15:59
Favicon

Re: LzNode.determinePlacement

This is one of those situations where nobody currently uses the  
parameter, but it might come in handy some day. Given that  
determinePlacement is optimized in the case where there are no  
overrides, there's not much overhead to passing it around. I agree as  
well.

On Nov 1, 2006, at 6:36 AM, P T Withington wrote:

> I agree.  When calling your super method, you should pass all the  
> arguments that you are called with.
>
> On 2006-10-31, at 21:36 EST, Philip Romanik wrote:
>
>> Hi Tucker,
>>
>> determinePlacement() has 3 arguments but most components only  
>> mention the first two (basetabs.lzx for example) when overridden.  
>> This is a bit of a nit, but I think all references to  
>> super.determinePlacement() should pass all 3 parameters. Or, is  
>> the third parameter cruft?
>>
>> Thanks!
>>
>> Phil
>>
>
Permalink | Reply | 7 comments |
headers
Jim Grandy | 1 Nov 16:13
Favicon

Re: LzEvent.sendEvent -> sendEvent

On Oct 31, 2006, at 3:07 PM, P T Withington wrote:

> So, thinking about this, 1490 is basically asking for the 'target'  
> to be passed.  In DOM1 the target is 'this' because adding a  
> handler adds it as a method on the event sender.  That clearly  
> can't work for us, because 99% of our handlers are methods on  
> another object.  In DOM2, what a handler gets is an event  
> descriptor object, with lots of properties.  Always at least the  
> target and some other stuff depending on the type of the event.  I  
> am wrestling with whether it is more important to pass multiple- 
> values to a handler or to pass more information about the event.
>
I had to make this choice in a couple of projects in the past, and  
was always glad in the end to have chosen an event descriptor. There  
are a number of ways this can be useful:

- as you mention, it is a clean way of passing complex information  
around as part of custom events

- event handlers can piggyback information on the event for use by  
handlers further up the event chain

- the kernel/LFC can add cheaply-computed secondary information (such  
as whether a click is part of a multi-click) to the event.

- it makes it *possible* to pass through extra pointer info (button  
number, pressure/angle for tablets) when available without going  
through painful acrobatics

It's just a really clean mechanism that works well.
(Continue reading)

Permalink | Reply | 3 comments |
headers
P T Withington | 1 Nov 17:22
Favicon

Re: LzEvent.sendEvent -> sendEvent

On 2006-11-01, at 10:13 EST, Jim Grandy wrote:

> On Oct 31, 2006, at 3:07 PM, P T Withington wrote:
>
>> So, thinking about this, 1490 is basically asking for the 'target'  
>> to be passed.  In DOM1 the target is 'this' because adding a  
>> handler adds it as a method on the event sender.  That clearly  
>> can't work for us, because 99% of our handlers are methods on  
>> another object.  In DOM2, what a handler gets is an event  
>> descriptor object, with lots of properties.  Always at least the  
>> target and some other stuff depending on the type of the event.  I  
>> am wrestling with whether it is more important to pass multiple- 
>> values to a handler or to pass more information about the event.
>>
> I had to make this choice in a couple of projects in the past, and  
> was always glad in the end to have chosen an event descriptor.  
> There are a number of ways this can be useful:
>
> - as you mention, it is a clean way of passing complex information  
> around as part of custom events
>
> - event handlers can piggyback information on the event for use by  
> handlers further up the event chain
>
> - the kernel/LFC can add cheaply-computed secondary information  
> (such as whether a click is part of a multi-click) to the event.
>
> - it makes it *possible* to pass through extra pointer info (button  
> number, pressure/angle for tablets) when available without going  
> through painful acrobatics
(Continue reading)

Permalink | Reply | 2 comments |
headers
P T Withington | 1 Nov 17:30
Favicon

Re: LzNode.determinePlacement

What you really want to be able to do is say:

   super.determinePlacement.apply(this, arguments);

But the compiler does not (quite) support that.  I spent a few  
minutes trying to see how hard that would be to support, and it was  
not just a quick fix (because of the way super is wedged in).

In most o-o languages I have used, there is a shorthand, like:

   super();

which means 'call the method I am overriding with the arguments that  
I got'.  I suppose we can't get away with that, because C++ has co- 
opted that to mean call my superclass's constructor.  But it sure  
would be convenient, since I think it is much more common to want to  
call the method you override and pass it all the same arguments that  
to want to call your superclass constructor.  [In our world you call  
super.initialize anyways, so there is no ambiguity.]

On 2006-11-01, at 09:59 EST, Jim Grandy wrote:

> This is one of those situations where nobody currently uses the  
> parameter, but it might come in handy some day. Given that  
> determinePlacement is optimized in the case where there are no  
> overrides, there's not much overhead to passing it around. I agree  
> as well.
>
> On Nov 1, 2006, at 6:36 AM, P T Withington wrote:
>
(Continue reading)

Permalink | Reply | 4 comments |

Gmane