Hi Alex,
All mx and spark class methods those were left empty for the compilation of
Application.
Also Module does not show anything on screen.
Thanks in Advance,
Alina
-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID]
Sent: Thursday, October 11, 2018 12:32 PM
I pushed changes to the compiler and framework to try to get callProperty to
work. I don't have a test case but give it a try and see what happens.
If you compare the size of the output with and without -js-dynamic-access, you
can see the theoretical savings of not using that option. If that
Hi Alex
El dom., 14 oct. 2018 a las 23:48, Alex Harui ()
escribió:
> I got the resources working so I will look into Proxy.callProperty.
>
>
That's cool, I'm closing for today, I can try in some hours if you upload
some changes. Thanks
> The issue with js-dynamic-access isn't about MX
Hi,
I just pushed support for old Flex resource bundles in Royale. Some people
migrating old Flex apps will find it more convenient and may even require that
[ResourceBundle] metadata works.
The interesting piece of this is that we can use the Flex resource bundles as
is. They don't need to
I got the resources working so I will look into Proxy.callProperty.
The issue with js-dynamic-access isn't about MX RemoteObject vs Basic
RemoteObject, it is whether, if we fixed places in any of the code where
minification breaks things, what the size/performance trade-off would be. Some
This is a different issue.
-Alex
On 10/14/18, 2:38 PM, "Carlos Rovira" wrote:
Hi,
That's why some months ago wanted to make Jewel not dependent of anything
that is not needed and removed Basic from its dependency list. Although now
Basic is again a dependency, I take care
Hi,
That's why some months ago wanted to make Jewel not dependent of anything
that is not needed and removed Basic from its dependency list. Although now
Basic is again a dependency, I take care of no load anything from Basic,
but UIBase that was carried again to Basic. I'm totally to add only
Hi Alex,
El dom., 14 oct. 2018 a las 18:32, Alex Harui ()
escribió:
> Hi Carlos,
>
> JS proxy doesn't support callProperty yet. Feel free to add it, or I will
> after I finish up ResourceManager.
>
JS proxy is mx.utlis.ObjectProxy or you mean maybe AbstractService
callProperty?
I could take a
Hi Alex,
filed here: https://github.com/apache/royale-compiler/issues/53
just say that for me, this bug is not critical since I don't use
mx:methods, but maybe others approaching mx:RemoteObject will need it, or
is very useful for new comers to RemoteObject-AMF technology.
thanks
El dom., 14
Before I contact Maven mailing list I would like to try again release to
see what I got.
On Sat, Oct 13, 2018, 11:28 AM Carlos Rovira
wrote:
> Hi, commit done and seems no other side effect was done. So I think the
> tweaks worked.
>
> El sáb., 13 oct. 2018 a las 11:18, Carlos Rovira ( >)
>
Subclasses just to get around this problem adds weight. It doesn't matter so
much for MXRoyale, but IMO this sort of thing may crop up elsewhere. We might
need to provide finer-grain control over dependencies in general. To me, the
base problem is that we pile every SWC into the
That’s problematic. I look at it that it’s a limitation that you have to
declare the dependencies in Maven. I’d rather that everything should just be
available.
What about subclassing the basic classes in MXRoyale so we don’t need to
declare new CSS dependencies for Basic components there?
>
Hi Carlos,
JS proxy doesn't support callProperty yet. Feel free to add it, or I will
after I finish up ResourceManager.
I don't doubt that minification breaks lots of things that js-dynamic-access
fixes. Hard to say how much smaller your app would be if we fixed anough stuff
without that
Ah yes, I hadn't thought about that. Folks only using Basic should probably
find a way to not include MXRoyale and SparkRoyale on the library-paths.
So I think some chocies are:
-Delete the MXRoyale and SparkRoyale swcs from frameworks/libs and
frameworks/js/libs.
-Explicitly list which SWCs
File a bug with a test case.
-Alex
On 10/13/18, 2:27 AM, "Carlos Rovira" wrote:
Hi Alex,
I get Responder/AsyncToken working with the current code.
But there's a bug:
To make it work I need to comment this part in the example
If not I get this
Same result.
From: Piotr Zarzycki
Sent: Sunday, October 14, 2018 4:51:56 PM
To: dev@royale.apache.org
Subject: Re: Royale Compiler Brings Wrong Dependencies
Maybe you should try point to the theme from Basic.
On Sun, Oct 14, 2018, 1:09 PM Yishay Weiss wrote:
Maybe you should try point to the theme from Basic.
On Sun, Oct 14, 2018, 1:09 PM Yishay Weiss wrote:
> No. We’re running the compiler-jx project with the following arguments:
>
>
>
> +royalelib="C:\dev\flexjs\royale-asjs\frameworks"
>
> +configname=royale
>
> -debug
>
>
No. We’re running the compiler-jx project with the following arguments:
+royalelib="C:\dev\flexjs\royale-asjs\frameworks"
+configname=royale
-debug
-closure-lib=C:\dev\goog\closure-library
--js-library-path+=C:\Users\Yishay\Documents\printui-flexjs\PortedPrintUI\lib
Hi Yishay,
Do you load during the build -theme?
Piotr
On Sun, Oct 14, 2018, 9:45 AM Yishay Weiss wrote:
> Hi,
>
> We’re seeing a bug where beads from MXRoyale are loaded even though the
> project doesn’t reference MXRoyale. This results in a runtime error when
> opening a ComboBox.
>
>
Hi Alex,
I get all my ROs converted to MX ROs in my real world royale app and
working with AsyncToken/Responder, like we use to do with Swiz (just left
the metadata features like Inject, EventHandler, etc...that will be pursued
later as I have the time), so I think this is really good news, since
Hi,
We’re seeing a bug where beads from MXRoyale are loaded even though the project
doesn’t reference MXRoyale. This results in a runtime error when opening a
ComboBox.
Specifically, it looks like these lines
Basic|ComboBoxList
{
IDataProviderItemRendererMapper:
21 matches
Mail list logo
