FrozenDice <[EMAIL PROTECTED]> writes:
> So I like the TreeFullControl Example #2 with the checkboxes, it's
> almost what I need. I want it to only have checkboxes on the lowest
> level. What I mean is there would only be checkboxes on leaves, and
> anything with children in it wouldn't have a c
So I like the TreeFullControl Example #2 with the checkboxes, it's
almost what I need. I want it to only have checkboxes on the lowest
level. What I mean is there would only be checkboxes on leaves, and
anything with children in it wouldn't have a checkbox.
This seems like it should be simple en
This is already known and mentioned in the newly created bug
http://bugzilla.qooxdoo.org/show_bug.cgi?id=462
Please note that the rework/fix will not be available with 0.7 final.
Sebastian
Dietrich Streifert schrieb:
> I've found the error by replacing console.warn with alert so I could see
Hello together,
how is it possible to set a complete Column Model via RemoteTableModel,
including visibility, sort ability and width of each column?
I've tried to call a function while _loadRowCount but then the result is
empty: no error, no table model.
Any Ideas?
Thank You,
Christian Bieser
I've found the error by replacing console.warn with alert so I could see
from which object the error comes.
But the problem remains that console is obviously not available in this
state.
Dietrich Streifert schrieb:
> Hello List,
>
> I get the following error on initialization of my applicatio
Hello List,
I get the following error on initialization of my application:
console is not defined
http://nra/qooxdoo.dev/frontend/framework/source/class/qx/core/Object.js
Line 170
I think this is due to an attempt to call dispose() on an object but the
warning is never displayed because console
Fixed in rev. 8374 of trunk as described below:
Dietrich Streifert schrieb:
> Hello List,
>
> one of the advantages of the new property system in qx 0.7 is the
> possibility to refine the init attribute, the default value of a property.
>
> In qx.io.remote.Request the properties "method" and "res
Sebastian Werner schrieb:
Dietrich Streifert schrieb:
Moin Sebastian,
Let's go back to the apply method:
What would be the cost of allowing the modification of the apply
attribute of properties?
This was my problem which lead to this thread.
Within a derived widget I wanted to overrid
Dietrich Streifert schrieb:
> Ok, so null is implicitly allowed if I define nullable: true right?
yes :)
>
>
> Sebastian Werner schrieb:
>> Hi Dietrich,
>>
>> nullable is the only requirement in 0.7. You can remove "null" from the
>> "check" list.
>>
>> Sebastian
>>
>>
>> Dietrich Streifert s
Hello List,
one of the advantages of the new property system in qx 0.7 is the
possibility to refine the init attribute, the default value of a property.
In qx.io.remote.Request the properties "method" and "responseType" are
defined as follows:
method :
{
check : [ qx.net.Http.MET
Ok, so null is implicitly allowed if I define nullable: true right?
Sebastian Werner schrieb:
Hi Dietrich,
nullable is the only requirement in 0.7. You can remove "null" from the
"check" list.
Sebastian
Dietrich Streifert schrieb:
Hello List,
on my way from 0.6.6 to 0.7 I've encounte
Hi Dietrich,
nullable is the only requirement in 0.7. You can remove "null" from the
"check" list.
Sebastian
Dietrich Streifert schrieb:
> Hello List,
>
> on my way from 0.6.6 to 0.7 I've encountered the following problem:
>
> I have a property which should be nullable and want to restrict t
Dietrich Streifert schrieb:
> Moin Sebastian,
>
> Let's go back to the apply method:
>
> What would be the cost of allowing the modification of the apply
> attribute of properties?
>
> This was my problem which lead to this thread.
>
> Within a derived widget I wanted to override the apply me
Hello List,
on my way from 0.6.6 to 0.7 I've encountered the following problem:
I have a property which should be nullable and want to restrict the
possible values with an array of allowed values. Because null is allowed
I tried the following:
busy :
{
check : [ "init", "load", "
Moin Sebastian,
Let's go back to the apply method:
What would be the cost of allowing the modification of the apply
attribute of properties?
This was my problem which lead to this thread.
Within a derived widget I wanted to override the apply method of the
superclass. It turned out that th
Dietrich Streifert schrieb:
> Well after digging around in Class.js if found that there is a method
> named patch. So instead doing:
>
> qx.Class.include(qx.ui.form.TextField,qx.visionet.ui.form.MTextField);
>
> I have to do
>
> qx.Class.patch(qx.ui.form.TextField,qx.visionet.ui.form.MTextField
Ok, there are multiple reasons. One major argument is that type changes
would allow to switch types completely e.g. from check=String to
check=Number for example. Most people would tend to say that this is a
bad software design.
Another, more technical reason, is that all other changes than ini
Not using one class per file I problematic. It will break a lot of stuff
e.g. things like the API viewer, the include sort system, the file
tracer (to find out the name of a class and its requirements). I would
say it by far easier to split files up than to support such things in
our build syst
Hello,
I'd like to implement a print view for my application so that the users
can print out the needed content. For this, I hide most of the widgets,
so that I only have a vertical box layout containing a toolbar, a table
and a status bar. The problem is that the table contains quite a few
en
Hello Nick,
thank you for that example code. Seems to be working very well. :)
Regards,
Daniel Haferkorn
Nick Glencross wrote:
> Basically when you set up the SimpleTableModel and call setColumns you
> are defining the number of columns which will be displayed. When you do
> your SetData to su
Hi Nick!
Thank you for your report. The problem was a missing overflow:"hidden"
for the FileUpload widget. I have corrected that and created a new
attachment to the bugzilla issue:
http://bugzilla.qooxdoo.org/attachment.cgi?id=178
The Problem behind this seems to be the TextField implementat
Hi Ruben.
ruben gonzalvez wrote:
> Hi Alex,
>
> I'm afraid of you don't understanme.
>
> I can build a simple textfile, button or icon,
>
> but I can't build the rest of things such as splitpane, textarea, .
What do you mean with this? Is the build process failing or does the
application thro
Leander Hanwald schrieb:
> Hi everyone,
>
> I tested Tibco some days ago and saw this nice little GUI Builder say have.
> But has far I can could see there lib isn't better then Qooxdoo, so why
> hasn't qooxdoo such a GUI Builder? :)
>
> So I tested for myself if qooxdoo can handle it, and yes I th
23 matches
Mail list logo