[LDTP-Dev] setappmap is not working (NameError: name 'setappmap' is not defined()

[Premkumar Jothimani]

Hi Mauricio,

You can use the second map file only while writing scripts. Because whatever
you see in the second map file is what will be present in appmap at runtime
after you do remap. So you can use the second map file just for reference
while writing automation scripts. You can check the correctness of the
script by executing the corresponding statement after a remap from a python
prompt.

Also you can make use of the following component functions. Unfortunately
they havent been documented yet. I will try to give a brief note on them.
You please try these and get back if you have any queries.

The following component functions help in retrieving values from appmap at
runtime. You can use them from python prompts (especially after a remap) to
know the current contents of appmap.

getwindowlist () - Returns the names of windows currently available in
appmap as a python list object.

getobjectlist ('window name') - Returns the names of objects currently
available in appmap under the given 'window name' as a python list object.
Please remember that the parameter window name should be one from the list
obtained from getwindowlist()

getobjectinfo ('window name','object name') - Returns the properties that
the given object posses at runtime.

getobjectproperty ('window name','object name') - Returns the values of the
properties of the given object name.

For example, for the following entry in appmap,
[frmInformation]
...
btnOK={class=push_button,parent=flr0,child_index=1,label=OK}

getobjectinfo('frmInformation','btnOK') will return ['class', 'parent',
'child_index', 'label']
getobjectproperty ('frmInformation','btnOK') will return ['push_button',
'flr0', '1', 'OK']

FYI, Most of the names generated for widgets will be straight forward from
their appearance in the window (like from their label/label by values). Also
remeber to do a undoremap () between successive remap calls.

Regards
Premkumar J

On 11/15/05, Mauricio Lin <mauriciolin at gmail.com> wrote:
>
> Hi Premkumar,
>
> On 11/11/05, Premkumar Jothimani <prem.jothimani at gmail.com> wrote:
> >
> > Hi Mauricio,
> >
> > I got the point. But I am puzzled as why setcontext does not work
> > (!!?!).
> >
> > Also I am worried that you will have to send the
> > advanced-linux-programming.pdf file along with your map file for things
> > to work as your map file expects that file to be opened initially. I dont
> > think it is such a good idea. An alternative solution would be to generate
> > the map file with none of the files open and use remap() at runtime. This
> > would make the map file look logical and simple.
>
>
> The problem is if you generate a map file (first map file) from a gpdf
> with no files loaded, gpdf does not display many widgets (buttons, menus)
> and then map file does not contain these widgets names.
>
> By other hand, if you generate a map file (second map file) from a gdpf
> with a file loaded as for instance advanced-linux-programming.pdf, your
> map file probably will contain more widgets.
>
> So the two map files are not so similar, since there are more widgets
> names presented on the second map file.
>
> If I remap at runtime I have to know in advance the name of widgets that
> are not presented on the first map file, right?
>
> How can I know these widgets names in advance if the first map file does
> not present them?
>
> Try to generate 2 map files, the first one just open the gpdf and appmap
> the application and the last one open gpdf with some pdf file and appmap the
> application. Compare these 2 map files and you can check they are different.
>
> I checked the remap function description, but how can I access dynamically
> created widgets if I do not know their names in advance?
>
> BR,
>
> Mauricio Lin.
>
> Regards
> > Premkumar
> >
> >
> > On 11/10/05, Mauricio Lin <mauriciolin at gmail.com > wrote:
> > >
> > > Hi Premkumar,
> > >
> > > On 11/10/05, Premkumar Jothimani < prem.jothimani at gmail.com> wrote:
> > > >
> > > > Hi Mauricio,
> > > >
> > > > Assuming that you use the map file that you sent me, I think your
> > > > setcontext() call should look like
> > > > setcontext ('PDF Viewer', 'python.pdf')
> > > > The point to note here is that the first parameter should always be
> > > > the value of the "label" field for that window name in the map file.
> > >
> > >
> > > OK. But there is a small detail here. The map file I generated starts
> > > as:
> > >
> > > [frmadvanced-linux-programming]
> > >
> > > frmadvanced-linux-programming={class=frame,parent=gpdf,child_index=0,label=
> > > advanced-linux-programming.pdf}
> > > ...
> > >
> > > Look the label field, it is not 'PDF Viewer'. The 'PDF Viewer' just
> > > exists if you generated a map file from a gpdf with no pdf file loaded.
> > > This map file was generated based on an open pdf file in the gpdf
> > > window.
> > >
> > > The reason I am generating the map file in this way is because a gpdf
> > > application with a pdf file loaded displays more graphical components
> > > (buttons, menu, menu options) that I want to manipulate.
> > >
> > > You can check that when you open a pdf file in gpdf, more buttons are
> > > displayed as well as more options in menu are created.
> > > Open the gpd application and afterward open a pdf file, you can notice
> > > that more buttons and menu options are displayed.
> > >
> > > BR,
> > >
> > > Mauricio Lin.
> > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/ldtp-dev/attachments/20051115/c1e5e843/attachment.html