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
>>>>
>>>
|