Lime 2.8.0 & Openfl 3.5.0 (overriden getter/setter)

Good evening,
Before the last haxelib upgrade, I was used to override getter/setter like that :

    #if flash @:getter(x) #end public #if !flash override #end function get_x():Float
        // invalidation system...
        return #if flash super.x; #else super.get_x(); #end
    #if flash @:setter(x) #end public #if !flash override #end function set_x(_f:Float): #if flash Void #else Float #end
        #if EComponent trace("EComponent.set_x( " + _f + " )"); #end
        if // invalidation system...
            #if flash
                super.x = _f;
        #if !flash
            return _f;

With such a way, I have now that compiler errors "Normal variables can not be accessed with ‘super’, use ‘this’ instead."
Using this, does not allow me to override flash getter/setter, it brings me “infinite loop”…
Any hint to retrieve the desired behavior ?

Would you mind trying to edit “openfl/display/DisplayObject.hx” in your install?

Perhaps changing #if (flash && !display) here could be #if (flash && !doc_gen), which may fix your issue?

Thanks to your quick answer, I tried it but it doesn’t fix anything.
I don’t even realise what !doc_gen is meant to. :sweat:

Okay, then it’s not related to code completion. “display” is defined when Haxe is performing code completion, or in our case, when we generate our documentation. The Haxe core code uses “doc_gen” as a define only for when generating documentation. There are cases where we blur the lines a little for documentation, since things need to match up exactly (like in this case, is it a property, or a getter/setter?)

Is this really related to Lime and OpenFL being updated? Did you update your Haxe install? I thought it was not possible to call super.x like this, I seem to recall trying to do something similar (and hitting a similar infinite loop on Flash) and having to give up :confused:

I have fought a whole mess for that, I admit, but it finally worked that way.
The haxelib upgrade seems to have updated that day…
• openfl 3.4.0 > 3.5.0
• lime 2.7.0 > 2.8.0
• swf 2.1.3 > 2.1.4

Even stranger ! Downgrading back to the previous versions brings me now the compiler error :

C:/HaxeToolkit/haxe/lib/openfl/3,4,0/openfl/display/GradientType.hx:26 characters 0-22 : Recursive typedef is not allowed.

I will try to locate the windows/html5 new issues with openfl 3.5.0/lime 2.8.0 tomorrow.
Anyway, It will be hard. Windows crash after an invalid cast popup, and I did forget how to trace() in HTML.

If you roll back to OpenFL 3.4 and Lime 2.7, be sure to do a -clean Flash build:

openfl test flash -clean

That will fix “recursive typedef” errors after downgrading. For HTML5, trace should work, but you need to open a debugger/inspector (usually Ctrl+Shift+I on Windows browsers) then hit the “console” tab

I believe the “use ‘this’ instead” error is Haxe related, not OpenFL related, but compare and lets see what happens :slight_smile:

Oh, great

there’s a “flash” package exception hard-coded in the compiler. We’re using “openfl” :confused:

The -clean has cleaned all my exported assets and previous/various compiled swf… :cry:

Sorry it sounds bad for you too.
Anyway, I still can override back my native flash getter/setter with openfl3.4.0/lime2.7.0/swf2.2

It should only clean your Export/flash directory, not your Assets or other directories. Was there something else in there? :frowning:

A lot of compiled swf and various assets, dynamically imported…
A loss of time to update all previous compiled swf and to export back my externs assets I guess/hope.

Will keep you informed of the windows/html5 new issues tomorrow.
Thank for your time.

If you can, maybe you can use an assets directory with ‘embed=“false”’ so it copies to the Export directory, without putting it in your SWF. That may help with allowing clean builds and would help if you test other targets as well. I’m so sorry for the setback :frowning:

I have one idea for solving the override issue, I’ll need to try it when I’m back to my desk :slight_smile:

I will definitely use that embed=“false” to avoid that in the future. Thanks.
Thanks too for the Ctrl+Shift+I too !!! Sure, It will help me a lot.

HTML5 Issue ?

(that worked with openfl 3.4.0 / lime 2.7.0 / swf 2.1.3)

URLLoader seems not to dispatch Event.COMPLETE…

function issue()
    var loader:URLLoader = new URLLoader();
    loader.dataFormat = URLLoaderDataFormat.BINARY;
    var url:URLRequest = new URLRequest("myDirectory/myFile");    
        // storing the loader in the LibraryManager occurence.
    catch (_e:ArgumentError)
        trace("### ArgumentError ### " + _e.message)
    //catch (_e:MemoryError)
        //trace("### MemoryError ### " + _e.message)
    catch (_e:SecurityError)
        trace("### SecurityError ### " + _e.message)
    catch (_e:TypeError)
        trace("### TypeError ### " + _e.message);

function registerListeners(_u:URLLoader):Void
    #if LibraryManager trace("LibraryManager.registerListeners( " + _u + "  )"); #end
    _u.addEventListener(Event.OPEN, onOpen);
    _u.addEventListener(ProgressEvent.PROGRESS, onProgress);
    _u.addEventListener(Event.INIT, onInit);
    _u.addEventListener(Event.COMPLETE, onComplete);
    _u.addEventListener(Event.UNLOAD, onUnload);
    _u.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onSecurityError);
    _u.addEventListener(HTTPStatusEvent.HTTP_STATUS, onHTTPStatus);
    _u.addEventListener(IOErrorEvent.IO_ERROR, onIOError);
function onOpen(_e:Event):Void
    #if LibraryManager trace("LibraryManager.onOpen( " + _e.toString() + " )"); #end
function onProgress(_e:ProgressEvent):Void
    #if LibraryManager trace("LibraryManager.onProgress( " + _e.bytesLoaded + " / " + _e.bytesTotal + " )"); #end
function onInit(_e:Event):Void
    #if LibraryManager trace("LibraryManager.onInit( " + _e.toString() + " )"); #end
function onComplete(_e:Event):Void
    #if LibraryManager trace("LibraryManager.onComplete( " + _e.toString() + " )"); #end
function onUnload(_e:Event):Void
    #if LibraryManager trace("LibraryManager.onUnload( " + _e.toString() + " )"); #end
function onSecurityError(_e:SecurityErrorEvent):Void
    #if LibraryManager trace("LibraryManager.onSecurityError( " + _e.toString() + " )"); #end
function onHTTPStatus(_e:HTTPStatusEvent):Void
    #if LibraryManager trace("LibraryManager.onHTTPStatus( " + _e.toString() + " )"); #end
function onIOError(_e:IOErrorEvent):Void
    #if LibraryManager trace("LibraryManager.onIOError( " + _e.toString() + " )"); #end

In the console, I retrieve well the expected trace with -DLibraryManager flag.

LibraryManager.registerListeners( [object EURLLoader] ) Main.js:10307:1
LibraryManager.onOpen( [Event type=“open” bubbles=false cancelable=false] ) Main.js:10318:3
LibraryManager.onHTTPStatus( [HTTPStatusEvent type=“httpStatus” bubbles=false cancelable=false status=200 redirected=false] )

Can’t be sure that the HTTPStatus one is a new one…
Any advice ? A random no-cache trick with the URLRequest ?

I think this should be resolved now, was specific to type BINARY on HTML5 (through a “cannot convert [ArrayBuffer] to” error at runtime)

I invalidate, it does not fire any INIT/PROGRESS/COMPLETE Event…
(with the latest haxelib upgrade : openfl 4.5.1 / lime 2.8.1)

Oh, I meant just today :smile:

You can patch your own install to see if it fixes it for you. This will go in the next OpenFL minor release :slight_smile:

yeah ! thank you.
no more issues on HTML5 (for me).
you’re magic.

should developp about the Windows target tomorrow.