Hi Thomas,
thron7-2 wrote:
>
> I'd rather have you not doing that. The #require and #use compiler hints
> are not designed to accept wild cards, and I wouldn't want them to do
>
Ok, I didn't know that - I always simply assumed their syntax would be like
python or java import statements.
thr
On 09.07.2010 15:43, thron7 wrote:
On 07/09/2010 03:11 PM, panyasan wrote:
#use(dialog.*)
to pull in all the classes, but this didn't work to activate the triggering
of the "defer" function. I had to separately specify all the classes that
were used:
#use(dialog.Alert)
#use(dialog.Prompt)
On 07/09/2010 03:11 PM, panyasan wrote:
> #use(dialog.*)
>
> to pull in all the classes, but this didn't work to activate the triggering
> of the "defer" function. I had to separately specify all the classes that
> were used:
>
> #use(dialog.Alert)
> #use(dialog.Prompt)
> #use(dialog.Confirm)
>
Chris:
thanks so much, that did it! Sometimes the answer is not difficult, but I
wouldn't have known that this was the problem.
I have fixed it in my local working copy and will commit tonight when I get
home.
BTW, I tried
#use(dialog.*)
to pull in all the classes, but this didn't work to ac
Hi Christian,
I added a patch to the bug report, which should fix the issue. Please
have a look on it.
Cheers,
Chris
Am 09.07.2010 10:24, schrieb panyasan:
> BTW, there is an open bug that I need help with that would be nice to get
> fixed before the next release:
>
> http://bugzilla.qooxdoo.
On 07/09/2010 10:22 AM, panyasan wrote:
>
> Before I release the next stable version of the dialog package, I plan to
> split up the wholesale definitions of the shortcuts in the defer key of
> dialog.Dialog and move them to the defer keys of the respective dialog
> widgets. I think that this is
BTW, there is an open bug that I need help with that would be nice to get
fixed before the next release:
http://bugzilla.qooxdoo.org/show_bug.cgi?id=3538
C.
--
View this message in context:
http://qooxdoo.678.n2.nabble.com/Cannot-get-the-Dialog-contrib-or-any-libraries-to-load-tp5266735p527345
Before I release the next stable version of the dialog package, I plan to
split up the wholesale definitions of the shortcuts in the defer key of
dialog.Dialog and move them to the defer keys of the respective dialog
widgets. I think that this is a cleaner way and allows a more "plug-in"-like
beha
I can reproduce it!
Please open a bug for it, attaching your minimal example. The generator
does not honor dependencies to name spaces, only classes. (There is also
no way for the generator to know that in order to derive 'dialog.alert'
it has to load dialog.Dialog :).
I.e., like Christian said,
After applying this logic to my main app, I go to generate the source and get
the following generator error:
"Unfullfilled dependency of class 'dialog.Dialog'[0]: 'dialog.alert'"
Which I do not get in my test app. I commented out the deferred shortcut
declarations in Dialog.js and all is right wi
There's definitely something I'm doing wrong, I'm just not sure what it is. I
started a Hello World application called "test" and arrived at the exact
same conclusion with the top level "dialog" variable missing. Here are the
exact steps I took:
Created Hello World application called "test"
Opene
thron7-2 wrote:
>
>
> Also, I think the name space for the contrib is just "dialog", and not
> "qcl.ui.dialog".
>
>
You're right, sorry, that was the wrong line! Should have been
/*
#require(dialog.Dialog)
***
It's working for me in a minimally adapted skeleton app, just as I
described in my other mail. - Must be something else.
Also, I think the name space for the contrib is just "dialog", and not
"qcl.ui.dialog".
T.
>
> Hi Nick,
>
> try this in your Application.js :
>
> /*
>
Hi Nick,
try this in your Application.js :
/*
#require(qcl.ui.dialog.Dialog)
*/
I don't have any alert or confirm dialogs in my app that are instanti
On 07/07/2010 08:41 PM, Nick Watkins wrote:
>
> This is the first time I've had any trouble getting a contrib to function,
> but it's also the first that requires loading as a library. Here are the
> steps I've taken:
>
> Made the change suggested a couple weeks ago to get around the new
> sour
Hi,
I don't think this is the problem, because I have removed the need to call
the init() function in the current trunk by using the defer key to
initialize the shortcut methods of the dialog package. Seems like the
liberaries are not correctly loaded since even the top-level "dialog"
variable do
This is the first time I've had any trouble getting a contrib to function,
but it's also the first that requires loading as a library. Here are the
steps I've taken:
Made the change suggested a couple weeks ago to get around the new
sourceforge uri format when including libraries remotely, and it
I think you forgot to initialize the dialog components. Do so with:
dialog.Dialog.init()
This has to be called once before using the dialog shortcut calls.
Hope this helps.
Alexander
--
View this message in context:
http://qooxdoo.678.n2.nabble.com/Cannot-get-the-Dialog-contrib-or-any-librar
18 matches
Mail list logo
