Re: Help with firing an event from a button

First Off.  Forgive me if this is a double post.  I seem to be having partial 
mail delivery failures when sending from my home machine.  I sent this about 
8 hours ago but never saw it make the list.  Also If anyone has outstanding 
questions this week that didn't receive a reply please fwd them to me again 
just in case :)  


On Wednesday 24 March 2004 08:10 pm, [email protected] wrote:
> First Question. Is this a good approach ?
>
> Second: Why can't I find the form object with findParentOfType()? should
> I walk up myself thru the tree to find it?
>

Forms triggers are implemented using gnue-common's trigger system.  This 
system creates a custom namespace in which the trigger will run.  It maps 
special handler objects (NamespaceElement) that act as an interface to 
objects in the form tree (gnue-forms internal form representation).  This is 
all done to hide complexity from the form trigger writer and to give us more 
control on how things are called.  We really don't want people trying to get 
back to the internal representation of the form's objects.  I'm sure it's 
still possible if one is determined but your forms will probably break in 
future releases. 

That's probably a nice and confusing paragraph I just wrote :)  So you can 
forget all of it for now and I'll explain a bit about you can access objects 
in a trigger. 

When you write a trigger in forms you have access to all the named objects 
you've defined in your gfd file, plus a few extra items.  So lets look at 
samples/zipcode/zipcode.gfd for a moment

In there we have the following piece of code

    <block name="zip" datasource="zips" rows="15">
      <field name="city" case="upper" field="city" required="Y">

You'll notice both those objects have names.  The block is named "zip" the 
field is named "city".  These names are available to you as a trigger 
programmer.  Lets say I want to have a button that prints the value in the 
record to the console.  Any one of the following 3 lines in your trigger code 
would work

print zip.city
print "%s" % zip.city
print zip.city.get()

For now lets set a value of "GNU York" to the city field.  Either of the 
following lines will work

zip.city = "GNU York"
zip.city.set("GNU York")

At this time I recommend that people use the get() and set() functions.  Due 
to the nature of the namespace system it is possible to get odd results at 
times.  I'll refrain from going into those details in this mail.  If someone 
really wants to know why let me know and I'll give more detail.  However it 
is  a level of detail not important to trigger writers.

You'll notice that in the examples above I treated zip.city as a text field, I 
also called functions against it.  Objects in the namespace have various 
functions defined against them.  I just took a look at the Forms Developers 
Guide (http://www.gnuenterprise.org/tools/forms/) and see while there is some 
data starting at page 26 it is very incomplete.  And thus doesn't list these 
functions :(  One more thing for the todo.  

Lets get the code you needed now.
> ## Perform list page up
> # form =  self.findParentOfType('GFForm')
> # if form != None:
> #   form.dispatchEvent('JUMPROWSUP');

If I understand what youre trying to do below you want the trigger to move 
thru the currently loaded records in memory.  

If you want to tell a block to move backward 1 record.
zip.prevRecord()

forward 1.
zip.nextRecord()

Note: If you have a form with multiple rows displayed, then when you click on 
your button focus will change to the button.  That is why you won't see 
cursor doesn't jump to the next record.  But the record counter in the lower 
right will reflect the change, and if you hit <tab> to shift focus off the 
button it will be in the new record.

Since these functions do not seem to be documented I'll pass on a trick to 
finding them.  You are welcome to ask here too of course as the rest of this 
deals with gnue-forms and gnue-common internals.

Almost every tag in the gfd format maps to a single .py file in the gnue-forms 
source.  The key files are gnue-forms/src/GFForm.py, and all those in 
gnue-forms/src/GFObjects/*.py.  We're going to have to go in here to find 
those functions.  But this isn't as bad as it seems.  We know that "zip" is 
the name of our block,  gnue-forms/src/GFObjects/GFBlock.py contains the 
internal representation of that <block> tag.  By looking in there we find a 
python dictionary named self._triggerFunctions.  If you look at it's 
definition you'll find the following entries. (pardon the line wrap)

'nextRecord':{'function':self.nextRecord,
                         'description':'Navigates the block to the next record 
in sequence.'},
'prevRecord':{'function':self.prevRecord,
                         'description':'Navigates the block to the previous 
record in sequence.'},

This is how gnue-common lets someone extend the trigger namespace.  

'exposedName' : { internalDefinition }

The exposedName as that is what you will use in the trigger.  So we have

objectName.exposedName or in the example above zip.prevRecord()

One thing worth mentioning about the internalDefinition.  If you happen to 
notice that it contains 'global': True  then this function is part of the 
global trigger namespace.  Basically you can treat it as a part of the 
trigger language built in functions.  An example of this is in GFForm.py

'showMessage':{'function':self.triggerShowMessageBox,
                                             'global': True,
                                             },

In any trigger in our form we can put

showMessage("Hi there!")

Typically these global functions require you to pass parameters, such as the 
message text I passed in above.  Unfortunately since this isn't documented 
you will need to look at the internal function that showMessage calls 
self.triggerShowMessageBox.  Searching thru GFForm.py we find 

def triggerShowMessageBox(self,msgtxt):

The self parameter is ignored as it normally is in class functions in python.  
Any remaining arguments will need passed in if not defined.  All standard 
python argument rules apply.

I hope this helps.

Take Care,
James