[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUe] Help with firing an event from a button
Re: [GNUe] Help with firing an event from a button
Thu, 25 Mar 2004 15:25:57 -0600
> exceptions.NameError: ("name 'myForm' is not defined",)
> if, instead, I do: form.showMessage('...'), it works fine, so it isn't
> critical ;).
In a trigger we always define "form" as the form. You don't need to track the
name of the form. I don't recall why we did this though.
However, you don't need to do form.showMessage('...'). Since showMessage is
set global inside the definitions it can be used without any object.
is all you need.
> But, for now, and just becuase I've been, as you suggest, looking at
> forms code, I found, at GFInstance.py, events labeled JUMPROWSDOWN
> and JUMPROWSUP. I also found shift-PgDn/PgUp instructed for listening
> to them at GFKeyMapper, but not so any toolbar button.
<boring technical crap on gnue internals>
Any time you see events mentioned inside the forms code base. You are dealing
with gnue-common's event dispatcher. These events are internal to the forms
code and and not meant to be exposed to the trigger programmer. The event
model was originally designed to keep us honest with regard to separating the
UI code from the internal representation of the form. When you are running a
form the following happens
The system reads the gfd and constructs what I call the "virtual form". The
virtual form is then used by the UI system to construct what you see on the
screen. Events are passed between the UI system and the virtual form for
everything. A simplified example would be when the user presses the letter A
for input into a field.
The UI detects the event and emits a request to the virtual form saying
"please change the field with focus using the data A" At this point the UI
is done dealing with that key press.
The virtual form receives the request and decides if it wants to do something
about it. It can make the change, make an entirely different change (such as
converting the input to/from upper/lower case), or simply ignore it. If it
decides to change something it alters the values inside itself. It then can
optionally emit an event to tell the UI to update itself to a new value.
So this means the UI is completely dumb in forms. No data on the screen means
anything to the virtual form. It also means that the UI drivers are free to
interpret how to display something in any way they want. You could create a
touch tone phone based gnue forms "UI driver" if you'd like. As long as it
responds to the defined set of events that are emitted by the virtual form.
For what it's worth, gnue-forms is probably the worse place to study
gnue-common events code :) It contained the original events code which was
later ported to common and improved in the process. I imagine gnue-pos would
be a better example of events usage as IIRC most it's sub components
communicate via events. Another source of cleaner gnue-common events usage
is in my pet project at www.adrius.org. All it's sub components communicate
via events as well.
</boring technical crap on gnue internals>
> What I'd like is having a button with that functionality, as toolbar has
> for next/previous/first/last records.
> I've been looking at GFBlock, and found that with block methods, I'll
> have to do a loop for '@rows' number or so. How can I get block/@rows
I dont understand what you are after here? Can you give more detail.
> In the other way, I suppose it should be possible to fire JUMPROWSXXX
> events that would do the job. I've tried form.dispatchEvent() also,
> but I got an Exception saying dispatchEvent was an unknown attribute,
> thought it's a method from GFForm.
Events are internal only. Trying to dispatchEvent() inside a trigger could
lead to deadlock situations. No methods from the GFForm should be run from
inside a trigger. If you need a function exposed that isn't you will have to
add it to GFForm's self._triggerFunctions dictionary. Depending on what you
are trying to do you might have to write a bit of wrapper code in their as
well. Before you start hacking forms internal structures you'd probably want
to post here first. As we may have a way of doing that already. If not,
we'd like to make sure it fits the direction we're headed. Then we could see
about adding it into the main code base for everyone to benifit from.
> And I've looking for a way to customize toolbar and found defined at
> ToolBar.py. I'm new to python, but I've seen, at documentation,
> that yo can derive a new class with same that parent: could I do that
> with ToolBar, redefining _DEFAULT_TOOLBAR and loading derived class via
> ImportPath to get a customized toolbar?
I don't think deriving a new class internally would be the way to do this.
We don't have a proper way to extend the toolbar/menu system yet. It's been
on the todo list for a long time but not a high priority for the people we
have available. Some efforts have been started though. What I'd like to see
is a completely generic (UI free) menu/toolbar definition system in
gnue-common. This system would provide basic XML definition for reuse in
common based apps and a set of trigger functions so that triggers could also
manipulate the menus/toolbars. This would be similar to how our data access
works and makes it quite easy for application designers to reuse the setup in
their own creations. I believe designer has a fairly nice dynamic menu
generator that could be used as a start point. I imagine such a system would
be usefull internally in at least designer, forms, and navigator, as well as
for forms designers.
James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561
Kansas State University Department of Mathematics