Adobe, Facebook partner to create Flash developer tools | Web Services | Macworld

Anyone up for writing a Facebook app in OpenLaszlo?

> The client library is a free open source programming language that  
> supports Facebook application programming interfaces (APIs)  
> including Facebook Connect.

[Adobe, Facebook partner to create Flash developer tools | Web  
Services | Macworld](http://www.macworld.com/article/139727/2009/03/adobefacebook.html?t=232 
)

Re: Adobe, Facebook partner to create Flash developer tools | Web Services | Macworld

OpenLaszlo 4.3 is Released

We are pleased to announce that OpenLaszlo 4.3 is available now. You can 
download it from the OpenLaszlo Download page 
(http://www.openlaszlo.org/download). It is the recommended platform for 
all application development for the SWF8, SWF9, and DHTML runtimes. 
OpenLaszlo 4.3 is a major release, with almost 300 bugs fixed since 
OpenLaszlo 4.2 introduced the SWF9 runtime.

For those of you who have already upgraded your applications to 
OpenLaszlo 4.2.X, no further work is needed. You should just start using 
OpenLaszlo 4.3.

To migrate your 4.0.X or 4.1.1 applications, we strongly suggest that 
you refer to this wiki page: Runtime_Differences. This page discusses 
the changes required by SWF9 and also provides a methodology for 
upgrading your application. It is very important that you run the 
automated conversion scripts in the recommended order, should you choose 
to take advantage of them.

This release also has a number of improvements, and significant advances 
in these areas:

     * Audio/Video APIs are working well in this release. Videoplayer 
and videoview now show the first frame of the video by default when they 
appear, if a URL has been set. (You can control this behavior with new 
starttime API.) Live broadcast and recording APIs are working in both 
swf8 and swf9. We have also added a new Audio & Video Programming forum 
(see http://forum.openlaszlo.org/)
     * Incubator components have been updated to work with the 4.3 code 
base.
     * A new documentation comments feature has been added, so that you 
can add an example or comment that expands upon the existing 
documentation or shows a non-obvious usage of a feature (or work-around 
for a bug that you have already filed) in OpenLaszlo. Documentation bugs 
or feature requests should be filed in our JIRA bug tracking system as 
in previous releases.
     * An improved debugger to deal with deep and circular objects when 
printing. The 4.3 release adds two new properties of Debug: 
printDepth:Number, default 8, limits how deep the debug printer will go 
into an object when printing it; inspectPrintDepth:Number, default 1, 
limits how deep the debug printer will go into an object that is a 
property of an object when inspecting. The debug printer will also 
detect circular objects (rather than causing a stack overflow), at small 
cost in overhead. When an object refers to itself (however indirectly), 
it will be printed just as its type and ID.

There is also an important change to the "this" behavior. In 4.2 and 
later, only declared attributes, i.e.: <attribute name="myattr" … /> can 
be referenced lexically (without saying "this".). The swf9 runtime will 
generate an error at compile time if you make a lexical reference to an 
undeclared attribute. For the swf8 and DHTML runtimes, the old behavior 
is supported but deprecated and may cause a compiler warning or error in 
future releases.

We would like to thank the entire OpenLaszlo community for submitting 
bug fixes and participating in discussions to help make OpenLaszlo a 
better platform. We'd also like to thank the incredible engineering team 
at G.ho.st, who have worked with us as a sponsor to bring SWF9 and many 
other improvements to the community. Special thanks to André Bargull and 
Raju Bitter for their continued and amazing support of the project. 
Special recognition goes to community contributors: Sebastian Wagner, 
Justin Clift, Ryan Maslar, Sarah Allen, and Wolfgang Stöcher. And 
heartfelt thanks to Phil Romanik, Don Anderson, Josh Crowley, and Lou 
Iorio for their tireless efforts and significant contributions.

swf9 method parameters mismatch causes hangs

I'm upgrading my large app to swf9 and having a very difficult time of
it. I've done all the things in the wiki and have a clean compile. The
app hangs whenever there is a call to a method where the caller has an
extra arg that is not in the method args list. This is not mentioned
in the wiki and there is no debug message printed! (It is easy, for me
at least , to sometimes forget the signature for methods called in
a dynamic-like manner.) My primitive debugging technique is to put in
Debug.writes, very time consuming with the depth of calls. Is this a
known problem? Any way to put out a message at the point it hangs?

http://wiki.openlaszlo.org/Runtime_Differences

A simple test case:

<canvas debug="true">
    <simplelayout axis="y"/>
    <view name="foo" width="100" height="100" bgcolor="red">
        <method name="meth">
            Debug.write('NOT PRINTED IF swf9!!!');
        </method>
    </view>
    <button text="foo" onclick="foo.meth(0); Debug.write('NOT PRINTED
IF swf9!!!');"/>
</canvas>

Thanks.

Re: swf9 method parameters mismatch causes hangs

oops...forgot to specify platform versions:

laszlo: 4.2.0.1
linux 2.6.18-53.el5: CentOS 5.2 64 bit
Firefox 3.0.6
Flash LNX 9,0,124,0

On Thu, Apr 2, 2009 at 7:18 PM, Gregory Denton <greg.denton@...> wrote:
> I'm upgrading my large app to swf9 and having a very difficult time of
> it. I've done all the things in the wiki and have a clean compile. The
> app hangs whenever there is a call to a method where the caller has an
> extra arg that is not in the method args list. This is not mentioned
> in the wiki and there is no debug message printed! (It is easy, for me
> at least , to sometimes forget the signature for methods called in
> a dynamic-like manner.) My primitive debugging technique is to put in
> Debug.writes, very time consuming with the depth of calls. Is this a
> known problem? Any way to put out a message at the point it hangs?
>
> http://wiki.openlaszlo.org/Runtime_Differences
>
> A simple test case:
>
> <canvas debug="true">
>    <simplelayout axis="y"/>
>    <view name="foo" width="100" height="100" bgcolor="red">
>        <method name="meth">
>            Debug.write('NOT PRINTED IF swf9!!!');
>        </method>
>    </view>
>    <button text="foo" onclick="foo.meth(0); Debug.write('NOT PRINTED
> IF swf9!!!');"/>
> </canvas>
>
> Thanks.
>

Re: swf9 method parameters mismatch causes hangs

Re: swf9 method parameters mismatch causes hangs

I'm guessing the thread in the forums is you too?  I posted some  
suggestions there:

http://forum.openlaszlo.org/showthread.php?t=13292

I would have hoped the Flash back end would have detected this error  
at compile time, but apparently not?  Please file a bug with your  
example case.  I think we could do better here...

On 2009-04-02, at 22:18EDT, Gregory Denton wrote:

> I'm upgrading my large app to swf9 and having a very difficult time of
> it. I've done all the things in the wiki and have a clean compile. The
> app hangs whenever there is a call to a method where the caller has an
> extra arg that is not in the method args list. This is not mentioned
> in the wiki and there is no debug message printed! (It is easy, for me
> at least , to sometimes forget the signature for methods called in
> a dynamic-like manner.) My primitive debugging technique is to put in
> Debug.writes, very time consuming with the depth of calls. Is this a
> known problem? Any way to put out a message at the point it hangs?
>
> http://wiki.openlaszlo.org/Runtime_Differences
>
> A simple test case:
>
> <canvas debug="true">
>    <simplelayout axis="y"/>
>    <view name="foo" width="100" height="100" bgcolor="red">
>        <method name="meth">
>            Debug.write('NOT PRINTED IF swf9!!!');
>        </method>
>    </view>
>    <button text="foo" onclick="foo.meth(0); Debug.write('NOT PRINTED
> IF swf9!!!');"/>
> </canvas>
>
> Thanks.

What should happen to a datapointer when you delete the node it is pointing to?

Re: What should happen to a datapointer when you delete the node it is pointing to?

I think that there is a simple answer here:  If you want your xpath to  
try to match in the face of deletions, you set `rerunxpath`.  If you  
don't have that on, and you delete the node that was matched, you  
should get `null`.  _Maybe_ the intent of the original author was that  
if you have a nextSibling and delete yourself then even without  
rerunxpath you can figure you ought to now bind tothe next sibling,  
but that's really not accurate [you could certainly construct an xpath  
expression that would _not_ match if rerun were on].

Bottom line:  I agree if you delete yourself and don't have rerun on,  
you should be null.  (Which means the documentation and test case need  
to be revised.  Which means you are proposing an API change...)

My 2p.

On 2009-04-03, at 19:57EDT, Henry Minsky wrote:

> Hi Laszlo Users,
>
> This was discussed previously in a thread in Laszlo-Dev, but we  
> realized we
> should probably get people's opinion
> from Laszlo User before deciding on the 'correct' behavior. I need to
> resolve this bug by either changing
> the regression test to match the current behavior or changing the  
> behavior
> of the deleteNode method back to the
> older behavior.
>
> The bug is http://www.openlaszlo.org/jira/browse/LPP-7461
>
> And was discussed on laszlo dev back in December:
> http://www.openlaszlo.org/pipermail/laszlo-dev/2008-December/018410.html
>
> Currently, the documentation says
>
> datapointer.deleteNode();
> Removes the node pointed to by the datapointer. If rerunxpath is  
> true and
> xpath has been set, it will be re-evaluated. Otherwise, if the  
> deleted node
> has a following sibling, the pointer is repositioned at that sibling.
> Otherwise the pointer is set to null.
>
>
> However, the current behavior actually will back up the pointer to a
> previous sibling if there is no next sibling.
>
>
>
>
> -- 
> Henry Minsky
> Software Architect
> hminsky@...

Problems / Solutions while porting existing OL 4.0.11 Application to OL 4.3.0

Hi List!

Here is a mail, that has become a little bit larger than expected. If 
you did not had any problems porting OL 4.0.xx applications to OL 4.3.0 
you can possibly stop reading now. But if you experienced problems or 
are one member of the development team you might be interested in some I 
wrote below.

I tried to port my Application - it is (was) written in OL 4.0.11 
conform code and I referred to the page 
http://wiki.openlaszlo.org/Runtime_Differences#4.2_Migration_Script to 
migrate my code to OL 4.3.0 conform code (should be the same as 4.2.0, 
right?).
This message to the board is a guideline on how to evade certain 
problems I have encountered... maybe it is useful to other programmers.

In addition this Mail is supposed to raise attention on some probs that 
are not very well documented :)

Well, what have I done? My Steps:

1. I ran the convert_required.pl migration script.

2. I ran the convert_setters.pl migration script.

So far, so good: The necessary changes had been made. But then I 
encountered a problem, which I solved manually - but I think it could be 
automatated in the Perl-Script:

3. I changed all the used Color-Keywords (like "black", "white", 
"green", ...) in the Tag-Descriptions and the setters 
(setAttribute('fgcolor',...), etc.) to their Hex-Values: black --> 0x0, 
white --> 0xFFFFFF, and so on. I am pretty sure this could be done by 
the perl script, but I have no idea about perl... or maybe there is 
another way?

That last Step eliminated all the remaining errors I had before my 
program started (it killed all the error messages in the debug-window 
before my inital "Program startet..." Debug-Message appears *Wohoo*).

4. I went through my code updating all the lines of my code that were 
instantiating self written classes. I added "lz." in front of the first 
few classes my program encounters. I am pretty sure this work can be 
done by one of  the perl scripts above too - just scan the class for 
appeareances of the sting "new *" and replace all occurences of  "new *" 
with "new lz.*". Should that do the trick or am I missing side effects?

5. I am using a red5-rtmp-connections (rtmps actually) including 
NetRemoteCalls. The netremotecall-Class is missing completely in the OL 
4.3 and in the OL 4.2 release - too bad. So I am using Sebastian 
Wagner's Code from an older Mail to the Laszlo-User-Mailing-List ("Re: 
[Laszlo-user] OL 4.2: NetRemotecalls annihilated?" from Sebastian Wagner 
send on Feb the 2nd of 2009). Works fine after one tiny little change: 
in the method "registerMethods" the line "var t = hib;" has to be 
deleted or commented - it does not do anything (that I could see :) ).

6. I have many calls to servlets in my code. One of the functions I used 
frequently is the OL 4.0.11 method "dataset.setQueryType(...)". This 
method is deprecated, but not changed by the perl script - should be 
easy to change that. It works currently for example for the "setSrc(..)" 
function of the dataset-class.

So far my experiences - please contact me if you need to know details.

And here are my Questions:

1. What happened to the "id"-Tags? Every object I referred to by the 
object's id could not be found anymore - the call points to an undefined 
object. As up now I have to relate directly to my used objects - but I 
miss that feature badly and I am sure this had not be abandoned!

2. Could be related to the first question: When I use the expression 
"foo = new lz.Delegate(...)" I can not call that "foo" link to the 
actual object later in the code - it points to an undefined object. 
Could that be abandoned as well?!

Ok - I hope I did'nt spread confusion - it may be I missed out some 
JavaScript Basics, because I am relatively new to that language...

Can anybody answer the questions above?

Kind regards
Tim