SoundChannel is a private constructor on HTML5

Haxe
#1

Hi, after compiling and running successfully on Flash target, a project that I’ve ported from ActionScript, when trying to compile for HTML I got some weird problems.
First of all, the flash target accepted some old dynamic access to properties on movieclip, which HTML didn’t compile.

var text = target_mc["label_txt"].text

I think it shouldn’t compile on Flash target either.
Anyway, after fixing this, The compiler don’t want to instantiate SoundChannel, because it complains that it’s a private constructor.
Why is it so? How can I overcome it?

#2

Can you show us what you’re doing? I’m using the SoundChannel class on HTML5 right now and everything seems to be working fine… Here’s my code:

this._sound = new Sound();
this._sound.addEventListener(Event.COMPLETE, completeHandler);
this._sound.load(new URLRequest(url_to_load));

And, at the COMPLETE handler:

// _channel is a SoundChannel instance
this._channel = this._sound.play(0);
this._channel.addEventListener(Event.SOUND_COMPLETE, soundComplete);
1 Like
#3

Oh, Wow. Thanks. :sweat_smile:
It appears that sound.play() is the only way to produce a sound channel.
So the main question remains - why did OpenFl compiled “new SoundChannel()” (which is, by the way, a totally legit assignment, even if it’s useless) to the Flash platform, but complained when compiling to the HTML platform?
It’s the same question about the array access to movieclip’s properties.

@singmajesty This is a question of understanding the compiler, more than a question of “how to”.

#4

Either OpenFL does not allow new SoundChannel because that’s how the API in Flash is meant to work, or perhaps we assumed you could not create a new SoundChannel this way, but it actually does work in Flash (even if it doesn’t do anything)

I’d be happy to look at it if you have more information about how it was used in Flash, and how Flash behaves in this regard

As for accessing MovieClip’s properties, you cannot access dynamic values that way. In Haxe, you use Reflect.field (movieClip, "nameOfField");

ActionScript is completely dynamic. That’s one reason Haxe performs faster, but it does mean that you don’t normally attach your own named properties to objects. There’s an exception to this in newer versions of OpenFL. We do allow dynamic field access on DisplayObject for children – not other types of objects, but you can access named children this way:

var sprite = new Sprite ();
var sprite2 = new Sprite ();
sprite2.name = "sprite2";
sprite.addChild (sprite2);
trace (sprite.sprite2);

That might help with porting some SWF code, for example (without a lot of getChildAt calls)

#5

The examples in Adobe documentation does instantiate the SoundChannel using “new”, but it’s useless. The right way, like Lucas mentioned, is snd.play() . The thing is that new SoundChannel compiled with Flash target, but not with HTML.
In my opinion, it should either compile with both targets, or not compile at all.

Same for accessing fields in DisplayObject. I did translate some of the calls to Refletion.field or getChildByName, and it worked well. But when switching to HTML, it complained about a million more places in which I needed to translate.

By the way, accessing properties dynamically, is essencial when converting from ActionScript, so thanks for this fix. :slight_smile: