On 1/7/19, 10:31 AM, "Harbs" wrote:
Details:
Requiring client code to check for defaultPrevented is bad. actionClick()
should not run.
I’m trying to prevent that. Event listeners added in addedToParent are run
after event listener declared in MXML. That’s
I'm all for strongly typed / static typed everything when available for
compile and run times. However here is some side information on the ECMA
(2015) typed arrays[1] and the ongoing discussion / notes for the full static
type implementation [2] that was proposed by Sirisian's (pretty
Looks like they were dealing [1] with a similar question.
[1] https://github.com/HaxeFoundation/haxe/issues/4526
From: Greg Dove
Sent: Monday, January 7, 2019 9:57:33 AM
To: dev@royale.apache.org
Subject: Re: Official Hack Proposal (was Re: [royale-asjs]
The only way I see of preventing the event from firing is to abort
fireListenerOverride in HTMLElementWrapper.
I can set defaultPrevented by attaching an event listener to the element in the
constructor of my class.
The question is whether we should abort the event dispatching if the event is
What's about setting up a default handler which always handles the click
event.
Depending on your conditions, maybe calling stopPropagation() or
stopImmediatePropagation() will prevent further propagation?
Maybe this helps,
Olaf
--
Sent from:
I mean that click events from the underlying HTML element automatically fire
from the Royale UIBase.
I have a button which pops up a menu when held for a second. If you release the
mouse over the button after the menu pops up, the browser fires a click event.
I only want a click event if
Hi Harbs,
I did something like that lately, but it is not what I wanted to figure out
how to achieve in Royale.
element.addEventListener('click', function(event:Event):Boolean {
event.preventDefault();
return false;
});
By prevent you mean do not
I have a component where I want to prevent the element click event from firing
from the component under certain conditions.
I’m struggling on how to best accomplish that.
Harbs
Essentially, you want to defeat strong-typing...
On 1/7/19, 2:34 AM, "Harbs" wrote:
> In your proposal, every place we fake the type, we have to use "as
BlobPropertyBag" and @royaleignorecoercion BloBPropertyBag.
No. I’m proposing making the compiler smarter so you *wouldn’t*
To be clear:
I have no objection to using factory functions run places where it makes sense.
My issue is more that we have no other option.
Thanks,
Harbs
> On Jan 7, 2019, at 12:34 PM, Harbs wrote:
>
>> In your proposal, every place we fake the type, we have to use "as
>> BlobPropertyBag"
In your proposal, every place we fake the type, we have to use "as
BlobPropertyBag" and @royaleignorecoercion BloBPropertyBag. Because otherwise,
your very first line:
var options:BlobPropertyBag = { type: "text/plain”};
will generate a compiler error as you wrote it. Plus you are
I feel like you’re not understanding me.
I’m proposing:
var options:BlobPropertyBag = { type: "text/plain”};
new Blob(null, options);
Which would compile to:
var options/** @type {BlobPropertyBag} */ = { type: "text/plain”};
new Blob(null, options);
Using my proposal, this will work in the new
Hi,
sorry for annoying you but there's something which I'd like to understand:
If I understand it correctly, the issue is caused by the recent Google
Closure thing which expects typed constructor parameters now.
If I got it right, Google Closure is used for the JS target only.
So, it seems to me
Some runtimes understand types. We should not defeat that. The runtime
optimization of types is usually better than untyped stuff. JS in the browser
is an exception and may be only a temporary popular runtime in the long term.
The pattern I proposed (createBlobPropertyBag) is a
14 matches
Mail list logo
