Opened 12 years ago

Closed 10 years ago

#1820 closed defect (fixed)

WinGRASS -- Multiple Map Display Lockup?

Reported by: ianhawboldt Owned by: grass-dev@…
Priority: normal Milestone: 6.4.3
Component: wxGUI Version: unspecified
Keywords: workspace Cc: martinl
CPU: x86-32 Platform: MSWindows XP

Description

WinGRASS 6.4.3-svn-r54145-429 Windows XP, SP3

If I load a vector poly layer into the "Display 1" tab, and then create a "New map display", and load another vector poly layer into the "Display 2" tab, then I have two maps in the same mapset which can be displayed side-by-side. Well and good...

If I then save this "dual-display" workspace, exit completely from GRASS, and then re-enter, and then try to load this newly-created workspace, everything "locks up" -- that is to say:

(1) No poly layers are displayed in the "Display 1 Map". (2) No poly layers are displayed in the "Display 2 Map". (3) Display 2 is locked -- I can't click on Display 1 and go back to it. (4) A gray window displays the message "Please wait, loading workspace..." and remains in view forever. (5) I can't exit from GRASS if I select /File/Exit or CTRL-Q. (6) I have to terminate the GUI "cmd-window" to get out of GRASS.

However, if I open this workspace from 6.4.2, then all is well -- both maps are displayed side-by-side correctly. This in spite of the fact that the new parameter "name=" was introduced in 6.4.3.

This is unfortunate, as I was hoping to use 6.4.3 in order to access the fixed-up Table Manager -- oh well.....for now I am using both versions back-and-forth as a workaround.

Apologies if this has been reported elsewhere, but I scrounged around in the tickets and couldn't find anything close.

Thanks, Ian Hawboldt

Change History (5)

comment:1 by annakrat, 12 years ago

Keywords: workspace added

I can't open workspace either (Ubuntu). An error dialog opens which says that parsing xml failed because of unknown encoding on the first line. When I replace encoding UTF8 to UTF-8 it starts to work. The encoding string comes from locale.getdefaultlocale()[1] in core/workspace.py.

Anna

in reply to:  1 comment:2 by martinl, 12 years ago

Cc: martinl added

Replying to annakrat:

I can't open workspace either (Ubuntu). An error dialog opens which says that parsing xml failed because of unknown encoding on the first line. When I replace encoding UTF8 to UTF-8 it starts to work. The encoding string comes from locale.getdefaultlocale()[1] in core/workspace.py.

hopefully fixed in r54219. Martin

comment:3 by annakrat, 12 years ago

Thanks, it is working for me now. Tested for grass 6.4 and 7.

Anna

comment:4 by ianhawboldt, 12 years ago

The WindowsXP version of WinGRASS 6.4.3-svn-r54192 still can't open a workspace which defines multiple map display windows. The symptoms remain unchanged from my original post.

I'm not a programmer, but maybe this traceback from the Command Console tab will help locate the problem:

=============================================================== Traceback (most recent call last):

File "E:\GRASS_6.4.3svn\etc\wxpython\lmgr\frame.py", line

875, in OnWorkspaceOpen

self.LoadWorkspaceFile(filename)

File "E:\GRASS_6.4.3svn\etc\wxpython\lmgr\frame.py", line

922, in LoadWorkspaceFile

maptree = self.gm_cb.GetPage(displayId).maptree AttributeError : 'Panel' object has no attribute 'maptree' ===============================================================

Thanks, IanH.

in reply to:  4 comment:5 by wenzeslaus, 10 years ago

Resolution: fixed
Status: newclosed

Replying to ianhawboldt:

The WindowsXP version of WinGRASS 6.4.3-svn-r54192 still can't open a workspace which defines multiple map display windows. The symptoms remain unchanged from my original post.

Sorry for a (very) late answer, the fix was in r54219 and probably some following commits. It seems you tested older r54192. It is possible that you cannot use the older workspace file and you need to create a new one. I consider this is fixed now according to comment:3. Please reopen if you have exactly the same error, or create a new ticket if you have a different one (although perhaps related).

I'm not a programmer, but maybe this traceback from the Command Console tab will help locate the problem:

Yes, traceback is always helpful.

Note: See TracTickets for help on using tickets.