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

[Premkumar Jothimani]

Hi Mauricio

Adding to my previous mail, please remove the underscore character from the
folder name also.

Regards
Premkumar J

On 11/25/05, Premkumar Jothimani <prem.jothimani at gmail.com> wrote:
>
> Hi Mauricio
>
> Atlast I have found out the correct reason for the problem (still trying
> to find a solution though). The problem is with the underscore ('_')
> charcter in the file name that you give. In the localisation part the '_'
> character is getting removed from the current string under processing. So
> the given label and the one obtained at run time with after removing
> underscore in it does not match. Please check it will work fine if the file
> name given is changed to 'text2.txt' (without underscore).
>
> we will try to fix it as soon as possible. Till then please use strings
> without '_' character.
>
> Thanks
> Premkumar J
>
> On 11/25/05, Mauricio Lin <mauriciolin at gmail.com> wrote:
> >
> > Hi Premkumar,
> >
> > On 11/24/05, Premkumar Jothimani < prem.jothimani at gmail.com> wrote:
> > >
> > > 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.
> >
> >
> > I put the hard code path in setcontext because I know the new title name
> > in advance . I generated a map file of gedit after opening text_2.txt file
> > to check the new title name. Take a look the beginning of such map file:
> > [frmtext_2]
> > frmtext2={class=frame,parent=gedit,child_index=0,label=text_2.txt
> > (~/mestrado/memory/gedit/txt_files) - gedit}
> > flr0={class=filler,parent=frmtext2,child_index=0}
> > ...
> > ...
> >
> >  I have done in this way just for testing it.
> >
> > Is there any reason to prevent the hard code path in setcontext() in
> > such situation?
> >
> > Please check the following code snippet, I think it will do it.
> >
> >
> > I followed your suggestion and put your code, but the same error keeps
> > happening. Any idea?
> > This kind of error in gedit is strange for me since I have used
> > setcontext in other scripts and it works well.
> >
> > Any idea?
> >
> > See the changed pyhton script (attached) please.
> >
> > BR,
> >
> > Mauricio Lin.
> >
> > .......
> > > 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/20051125/42cd94c0/attachment-0001.html