Ticket #279 (closed defect: fixed)

Opened 4 years ago

Last modified 4 years ago

Problem with highlight preferences at Windows XP

Reported by: ignotus Owned by: boltrix
Priority: medium Milestone: Umit 1.0RC
Component: Umit Version:
Keywords: Cc:

Description

When the user clicks the 'Preferences' at highlight bar, and then close the preferences window the following error is shown and some tags in textview are not applied anymore.

Traceback (most recent call last):
  File "C:\Documents and Settings\ignotus\My Documents\umit\umit\gui\NmapOutputViewer.py", line 245, in show_output_properties
    self.__create_tags()
  File "C:\Documents and Settings\ignotus\My Documents\umit\umit\gui\NmapOutputViewer.py", line 123, in __create_tags
    tag_table.add(tag)
ValueError: A tag named 'hostname' is already in the tag table

Attachments

NmapOutputViewer.py.diff (1.2 kB) - added by lupa 4 years ago.
This patch solves the problem. Tha patch removes existing tags (that we know the name) before add them again.

Change History

Changed 4 years ago by ignotus

  • summary changed from Problem with highlight preferences at windows to Problem with highlight preferences at Windows XP

Changed 4 years ago by lupa

I gave a look at the code and I guess that the problem is at the line 83 on NMapOutputViewer.py:

tag_table.foreach(lambda tag, table: table.remove(tag), tag_table)

This line supose to clear the tag_table, am I rigth?

Well I gave a look at the gtk.TextTagTable? (tag_table class) and I found that the table must not be modified (add or remove tags) when using the foreach method.

I didn't figure out a way to solve this problem. I hope this information is useful, I'll gave another look on this later.

Changed 4 years ago by lupa

This patch solves the problem. Tha patch removes existing tags (that we know the name) before add them again.

Changed 4 years ago by gpolo

  • milestone changed from Umit 1.0beta2 to Umit 1.0

Changed 4 years ago by gpolo

I don't seem to get this, yet this "foreach" usage is very against its documentation. This change happened on r2964 (ticket #6), which somehow, for some reason, seemed to work at that time.

Changed 4 years ago by gpolo

  • milestone changed from Umit 1.0 to Umit 1.0beta3

Changed 4 years ago by ignotus

Lupa's patch seems to work well. Although there is a ticket #293 that claims to solved this problem and others with the same milestone. May we commit lupa's patch or wait for the other ticket? What you think getxsick?

Changed 4 years ago by getxsick

I think that I work on UMPA currently and don't have a time to look after of #293. But I'm hoping that #293 would be finish for beta3 and it means that this ticket is for beta3 also, so lets wait till someone (maybe me?) will make that refactor first. If not, then we can commit it.

Changed 4 years ago by luis

It can be commited.

Changed 4 years ago by getxsick

  • status changed from new to closed
  • resolution set to fixed

According to our policy, i allowed myself to commit the patch after 5 days of waiting to be commited by lupa.

r5138 provides this patch.

Note: See TracTickets for help on using tickets.