gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnue-dev] user-customizable forms?


From: Harald Meyer
Subject: [Gnue-dev] user-customizable forms?
Date: Mon, 1 Apr 2002 08:35:44 +0200

Hi,

yesterday I spoke with my mother about the software she is using in her
job. She told me that she is able to customize the forms in this
software. She can select which fields are visible and in which order. I
understand that this is already possible with gnue using the designer,
but I don't think this is a good way, because the user sees too much
and maybe changes something which he/she doesn't understand.

To test customizable forms, I tried to implement a trigger-based
solution and failed.

1.) just change the attribute:
 blkDokumente.inpTitel.Hidden = True
this works so far, that it actually changes the attribute, but it does
not change the visibility of the widget

2.) tell forms to reparse the attributes
any idea? I do not completely understand and know the sourcecode, so I
do not know if this is possible. But I tried, at least, two ways:
    a.) call form.refreshDisplay()
          tells me that it has no such attribute. Calling
form.GetObjectType() tells me its a GObj.               Doesn't python
use polymorphism or is it a restriction gnue forms uses to prehend such
          modifications?
    b.) calling the constructor of the block directly
          Gives me a warning from GTrigger:
            DB000: [f:\Programme\Python21\gnue\common\GTrigger:191]
Trigger attempting to re
            set a form object

3.) Hiding the widget directly
How can I do this? The problem is to find the mapping GFObj -> Widget.
Looking at the UIdriver of wxWindows tells me that it uses dictonaries
with the wxWindows id as an index. Is there another way to find this
mapping, because I've got no UIdriver object to access the dictonaries
and I don't know the ids either (as triggers don't get them).

If a trigger-based solution is not possible, what do you think about
implementing this as a feature in gfclient?
If both solutions are possible I would favour a trigger-based. It might
be more complicated to build customizable forms this way, but one could
use a designer wizard to make it. And it has the advantage that a form
designer can choose whether or not certain fields are disable-able and
that different ways of customisation can be implemented without
changing designer or forms.

Harald Meyer





reply via email to

[Prev in Thread] Current Thread [Next in Thread]