Re: [GNUe] Help with firing an event from a button

[James Thompson]

>
> 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.  

showMessage('...')

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.

blockName.nextRecord()
blockName.prevRecord()
blockName.firstRecord()
blockName.lastRecord()

> 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
> value?

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.

Take Care,
James

-- 
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson    138 Cardwell Hall  Manhattan, Ks   66506    785-532-0561 
Kansas State University                          Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<