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

[Premkumar Jothimani]

Hi Mauricio

I tried with your files. The problem is that your not doing setcontext()
before calling remap() which you have to do. Infact you have commented the
setcontext() there (line no 53). And when doing the setcontext() u should
not hard code the path that will be displayed in the title bar. you have to
include a logic that will do it appropriately. Please check the following
code snippet, I think it will do it.

.......
default_dir = os.getcwd() + '/txt_files'
#This can be any name that you choose for the file to be saaved
filename = 'sample.txt'
mo = re.match (os.path.expandvars ('$HOME'), default_dir)
if str(mo) != "<type 'NoneType'>":
       newcontext = '~' + default_dir [mo.end():]
 else:
      newcontext = default_dir
setcontext ('Unsaved Document 1 - gedit', filename + '(' + newcontext  + ')
- gedit')
......

FYI, the reason to include setcontext() is that, then only ldtp engine will
be able to locate the window on which remap() should be performed (since we
get the window handle based on the label (title) of the window).

After this remap() should work.

Thanks
Premkumar J

On 11/24/05, Mauricio Lin <mauriciolin at gmail.com> wrote:
>
> Hi Premkumar,
>
> I am trying to use remap() function in my gedit script but no success so
> far.
>
> Look the error:
>
> Traceback (most recent call last):
>   File "./gedit_2.py", line 65, in ?
>     appendtext('frmUnsavedDocument1-gedit', 'txt0', chr(number))
> ldtp.error: Window: frmUnsavedDocument1-gedit not opened
>
> I am attaching the script and map files, so you can check them for more
> details. You have to create a directory named as "txt_files" in the same
> place you are going to run the script.
>
> Basically the first time I save the file, widgets are changed, so I need
> to handle them afterwards.
>
> After using remap() function as below:
>
> remap('gedit', 'frmUnsavedDocument1-gedit')
>
> I print the names of windows currently available -> print getwindowlist()
>
> The printed list is the windows of the original map file and not the map
> file got in runtime.
>
> Is there anything wrong?
>
> BR,
>
> Mauricio Lin.
>
> On 11/15/05, Premkumar Jothimani <prem.jothimani at gmail.com> wrote:
> >
> > 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/20051124/8ad8ff24/attachment.html