JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for CCPNMR Archives


CCPNMR Archives

CCPNMR Archives


CCPNMR@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CCPNMR Home

CCPNMR Home

CCPNMR  March 2012

CCPNMR March 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Markers in Windows 2.1.5

From:

Richard Harris <[log in to unmask]>

Reply-To:

CcpNmr software mailing list <[log in to unmask]>

Date:

Wed, 14 Mar 2012 13:01:35 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (231 lines)

Hi Wayne

So the problem I had with the traceback was because I didn't do the exact corrections in the ScrolledWindow.py (didn't do in the indent left)

So everything now works and I actually prefer the behaviour that the window the cursor is over comes to the top and is active - I was often forgetting to click in the window to make it active so that I could pan and scroll and so it was doing it in a different window. But I am only using the Windows version for a NMR course so you might want some proper Windows users to decide if this is good or bad.

thanks
Richard

________________________________________
From: CcpNmr software mailing list [[log in to unmask]] on behalf of Wayne Boucher [[log in to unmask]]
Sent: Tuesday, March 13, 2012 1:44 PM
To: [log in to unmask]
Subject: Re: Markers in Windows 2.1.5

Hello,

The second message arrived first, which was confusing.

Are you on Windows 7?  That's the Windows version I have, although that
might not matter.  I can't seem to reproduce this but it's possible I'm
just not doing the right combination of clicks / key presses.

The one thing that I noticed which I think might be able to cause such an
exception is in ccpn/python/ccpnmr/analysis/frames/WindowFrame.py at
around line 285 (but your lines might not quite match up) we have:

     if not isWindowsOS():
       scrolledWindow.canvasBind('<Button-4>', self.zoomIn)
       scrolledWindow.canvasBind('<Button-5>', self.zoomOut)
     else:
       self.windowPopup.bind('<MouseWheel>', self.windowsZoom)
       #self.windowPopup.bind('<KeyPress>', self.keypress)

I would try commenting out that last line.  I suspect it must have been
there because key events were not coming through without that, but I just
tried and it seems ok for me.  And the reason that exception arose is
because the keypress() function was given an event that did not arise from
one of the strip canvases, and that bind above could well be causing that.
Of course if commenting that out means you lose your keypress
functionality that would not be good.

Wayne

On Tue, 13 Mar 2012, Richard Harris wrote:

> Hi Wayne
>
> sorry wrote too soon
>
> I made the changes but its still not changing focus for the z chemical shift window
> and I get attached traceback - couldn't figure out to copy and paste from the 'terminal' style window so did a screenshot instead
>
> Richard
> ________________________________________
> From: Richard Harris
> Sent: Tuesday, March 13, 2012 12:38 PM
> To: CcpNmr software mailing list
> Subject: RE: Markers in Windows 2.1.5
>
> Hi Wayne
>
> Well that solved the problem. I didn't notice any issue with the window focus though!?! Its behaving just as it was - I have to click in another window to bring it to the front and make it active. So all of the upside and none of the downside!
>
> thanks
> Richard
>
> ________________________________________
> From: CcpNmr software mailing list [[log in to unmask]] on behalf of Wayne Boucher [[log in to unmask]]
> Sent: Tuesday, March 13, 2012 11:32 AM
> To: [log in to unmask]
> Subject: Re: Markers in Windows 2.1.5
>
> OK, this is where the plot thickens.  So it turns out that the reason we
> have that hack from the previous email to determine x, y is because in
> Windows we took out a call to focus on the main window when you enter it,
> and it looks like the consequence of that is as you observed, so once the
> focus is in that z coordinate entry box, the focus never leaves there.
>
> Now it turns out the reason we removed the focus call in the Windows case
> is because on Windows if the application is itself in focus then moving
> the mouse over any window automatically brings that window to the top
> above other windows, and we thought that that was irritating beyond
> belief.  But I suspect it is better to live with that irritation than the
> irritation of losing focus completely.
>
> If you can edit the code and want to try this out to see the issue, then
> proceed as follows.
>
> Edit ccpn/python/memops/gui/ScrolledWindow.py.  Find the enter() function
> and change:
>
>     if not isWindowsOS():
>       event.widget.focus()
>
> by removing the first line and moving the second line two spaces to the
> left (so it should line up where the "if" used to be).  And do the same in
> the slice_enter() function.
>
> Then edit ccpn/python/ccpnmr/analysis/frames/WindowFrame.py.  In the
> keypress() function just comment out the modifyKeyEvent() call:
>
>     #if isWindowsOS():
>     #  self.modifyKeyEvent(event)
>
> Wayne
>
> On Mon, 12 Mar 2012, Richard Harris wrote:
>
>> Thanks Wayne
>>
>> Have noticed another 'feature'. Its a problem with using keyboard
>> shortcuts after you type in a chemical shift value in the bottom left
>> hand corner of the 3D window to select a specific plane. The typing
>> cursor stays in where you type in the number - so if you now try to type
>> 'm' for mark in the spectrum itself then it just goes into the chemical
>> shift part and does not create a mark, the only way I found I could use
>> the keyboard shortcuts was to close the 3D window completely and re-open
>> it.
>>
>> Richard
>> ________________________________________
>> From: CcpNmr software mailing list [[log in to unmask]] on behalf of Wayne Boucher [[log in to unmask]]
>> Sent: Monday, March 12, 2012 2:32 PM
>> To: [log in to unmask]
>> Subject: Re: Markers in Windows 2.1.5
>>
>> OK, I've figured it out.  It turns out that the way Windows handles the
>> x,y coordinates of events when you have multiple strips is completely
>> different than in Unix, and in particular you get the x, y of the point
>> relative to the top left of the window rather than relative to the strip
>> top left.
>>
>> So we added a function just for Windows which corrects for this.  It
>> corrects for y by subtracting off the height of the toolbar (already
>> something that worries me).  It corrects for x by figuring out which strip
>> you are in (if there is more than one) and subtracting off the relevant
>> number for this (which can only be obtained by looking at where the point
>> is relative to the top left of the screen).
>>
>> This was missing logic to exactly deal with the case when the mark was in
>> the last strip, so the x was coming out relative to the top left of the
>> screen instead of relative to the top left of that last strip.
>>
>> Anyway, this will be fixed in the next (2.2.2) release.  If you can figure
>> out how to edit the code (you probably need Administrator priviliges) then
>> in the file ccpn/python/ccpnmr/analysis/frames/WindowFrame.py look for the
>> function modifyKeyEvent() and you'll see:
>>
>>     else:
>>       for col in range(ncols-1):
>>         canvas = canvases[0][col+1]
>>         #print 'modifyKeyEvent: in x loop:', col, x, canvas.winfo_rootx()
>>         if x < canvas.winfo_rootx():
>>           canvas = canvases[0][col]
>>           x = x - canvas.winfo_rootx()
>>           break
>>       else:
>>         canvas = canvases[0][ncols-1]
>>         x = x - canvas.winfo_rootx()
>>
>> where the bottom three lines are extra (i.e. the fix).  Your email client
>> has probably mashed the indentation: that final "else:" should be lined up
>> with the "for" (i.e. the "e" in the same column as the "f"), and the other
>> two lines indented two spaces extra relative to that.
>>
>> Further down the y also needs changing:
>>
>>     else:
>>       for row in range(nrows-1, 0, -1):
>>         canvas = canvases[row-1][0]
>>         #print 'modifyKeyEvent: in y loop:', col, y, canvas.winfo_rooty()
>>         if y < canvas.winfo_rooty():
>>           canvas = canvases[row][0]
>>           y = y - canvas.winfo_rooty()
>>           break
>>       else:
>>         canvas = canvases[0][0]
>>         y = y - canvas.winfo_rooty()
>>
>> So again the three lines at the bottom are extra.
>>
>> Wayne
>>
>> On Mon, 12 Mar 2012, Richard Harris wrote:
>>
>>> Hi Wayne
>>>
>>> Yes that is what I am seeing just the last (righthand most) strip window - I didn't realise that the vertical portion of the mark was offset.
>>>
>>> richard
>>>
>>> ________________________________________
>>> From: CcpNmr software mailing list [[log in to unmask]] on behalf of Wayne Boucher [[log in to unmask]]
>>> Sent: Monday, March 12, 2012 1:29 PM
>>> To: [log in to unmask]
>>> Subject: Re: Markers in Windows 2.1.5
>>>
>>> One other thing I just noticed.  In the last strip, it is in fact creating
>>> a proper mark, both horizontal and vertical, it's just that the vertical
>>> one is at some semi-random (unintended) location, i.e. not where you
>>> clicked, so you just don't see it on the screen.
>>>
>>> Wayne
>>>
>>> On Mon, 12 Mar 2012, Wayne Boucher wrote:
>>>
>>>> Hello,
>>>>
>>>> Just trying it now, it looks like the Marks are created ok except for the
>>>> rightmost strip (when there is more than one strip), is that what you are
>>>> seeing, or is it not working for any set of strips.  (So one of the weird
>>>> things is that it is working ok for me if there are no strips.)
>>>>
>>>> Wayne
>>>>
>>>> On Mon, 12 Mar 2012, Richard Harris wrote:
>>>>
>>>>> Hi All
>>>>>
>>>>> I think there might be a bug in the 2.1.5 Windows version.
>>>>> When putting a Mark on a spectrum in a 3D window that is not H(x), N(y) it
>>>>> seems to only draw a horizontal line rather than a full mark. I've seen
>>>>> this behaviour in both a H(x), H(y), N(z) and H(x), C(y), N(z) windows, but
>>>>> it marks fine in the orthogonal windows - H(x), N(y), C/H(z) windows.
>>>>>
>>>>> Richard
>>>>
>>>

Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager