Robert Shiplett wrote:

Someone keeps saying I must be doing something wrong, the ini file must be wrong .... execution in Windows in dependent on two settings of PATH in env var's ... and Win drag-drop in Explorer would have to be broken

I hope you don't take it to heart.�� Its a process of eliminating what the things we can think of - when there is not a steps-to-reproduce.

As I say, what obscure PATH issue could that have been ? ��

And I am still trying to find a sure set of steps to reproduce ... having had the misfortune of hitting these 2 bugs ... and in the process finding that World | Windows ��has some menu quirks / ineffective actions

I've reproduced your issue:�� "World > Windows > Send top window to back."�� Nice find. Actually I've never used the Window menu myself.

I start looking into it by bringing up halos on the menu item ( <Shift-Alt-click> on MS Windows) thenclicking on the spanner "Debug" icon and from its menu selecting "Inspect Morph".�� This�� opens an inspector on a ToggleMenuItemMorph. Browsing its instance variables discovers _target_ holds���� [ SystemWindow sendTopWindowToBack ] and putting a halt in method #sendTopWindowToBack indeed triggers the breakpoint when using menu item.

SystemWindow class >> sendTopWindowToBack
������ TopWindow ifNotNil:
������ ������ [TopWindow sendToBack]

Now stepping through this didn't highlight anything obvious, but something seemed strange so I replaced the halt in #sendToWindowToBack with
������ Transcript crShow: TopWindow.

which then displayed "nil" in th Transcript window.�� Now from the context-menu on TopWindow, selecting "Extended Search... > references to it" bring a list of thirteen methods, but only the following two methods stored into the class variable _TopWindow_
* basicActivate
* passivateTopWindow

so at the top of each of those putting...
���� ������ Transcript crShow: thisContext printString.

gives an interesting result that
* #basicActivate is called when clicking on windows, and
* #passivateTopWindow is called when the World Menu is shown.

Now going back to through releases I find this issue has existed since Pharo 1.1 - and you are the first to discover this issue - so I'd say your doing well with your shakedown.

I find that Pharo 1.0 works and doesn't have #passivateTopWindow,

Pharo 1.1 has one sender of #passivateTopWindow which is PasteUpMorph>>mouseDown:
with that having the following as the major modification from Pharo 1.0...
������ self isWorldMorph ifTrue: [
�������������� self currentWindow ifNotNilDo: [:topWindow |
�������������� SystemWindow passivateTopWindow]].������ "since pasteup will release keyboard focus now"

SO NOW THE FIX...
Tracing through SystemWindow>>sendToBack shows this relies on "self world submorphs" returning an Array ordered from top window to bottom window.�� So we can similarly rely on this to do...
������ SystemWindow class >> sendTopWindowToBack
������ ������ "Send the top window of the world to the back, activating the one just beneath it"
�������� ���� �� |�� topWindow backWindow |
���� ���� �� ActiveWorld�� submorphs do:
���� ���� �� [ ������ :morph |
���� ���� �� ������ morph isSystemWindow ifTrue:
������ ������ �� �� [������ topWindow ifNil: [ topWindow := morph ].
������ �� ������ �� ������ backWindow := morph.
������ �� ������ �� ].
������ ������ ].
���� ���� �� topWindow notNil ifTrue:
���� ���� �� [������ ActiveWorld addMorph: topWindow behind: backWindow.
�� ������ �� ].

cheers -ben

r

On 27 February 2014 01:34, Tudor Girba <tudor@tudorgirba.com> wrote:

Thanks for reporting.

What obscure path issue?

Doru

On Wed, Feb 26, 2014 at 7:01 PM, Robert Shiplett <grshiplett@gmail.com> wrote:

I am dragging the image onto the pharo.exe in a newlynamed folder using an install whose README says date of Feb 25

��

COPY

��

Pharo 3.0

This distribution was built February 25, 2014.

��

as for that pharo.exe

��

created and last mod date is 12 7 2013

��

the dir is

��

���� C:\Pharo3.0-winB\Pharo3.0

��

and the dates for that Pharo3.0 dub-dir is today a few hours ago

��

so if a drag-drop of

��

Pharo-30782.image

��

onto that exe in that same folder has some obscure path issue, that is a worry I would think.

��

��

On 26 February 2014 08:52, Torsten Bergmann <astares@gmx.de> wrote:

Dear Robert,

I doubt that it is a general issue as I regulary try on various XP combinations
(even today) and therefore guess that it is a local problem on your single machine.

As you have other images and older VM's floating around it may be an
issue that you start the image with an old outdated VM.

Note that when you double click the image to start the Windows OS will use the
executable (VM) which is associated with the *.image extension. If you had
older VM installations (Squeak or other) this may conflict.

Just to make sure can you please exactly follow these steps:

��1. download and extract http://files.pharo.org/image/30/latest.zip in a fresh directory
��2. download and extract http://files.pharo.org/vm/pharo/win/stable.zip into the same directory
��3. go to this directory and drag the Pharo image "Pharo-30782.image" onto the "Pharo.exe"
�� �� to make sure the system is exactly started with this combination and no other VM or image
�� �� is involved

Then tell us if this works or (if it still fails) what the system reprorts to you
initially.

You should also check: in World Menu -> "Tools" -> "SystemReporter", there you
should check the entry "VM general" which will tell you excactly the VM you
are running on.

If you select all entries in this "System Reporter" you can send the report here
so we know more about your environment.

Thx
T.

--

www.tudorgirba.com

"Every thing has its own flow"