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. |
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 <[hidden email]> wrote: Dear Robert, |
Thanks for reporting. What obscure path issue? Doru On Wed, Feb 26, 2014 at 7:01 PM, Robert Shiplett <[hidden email]> wrote:
"Every thing has its own flow"
|
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 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
r On 27 February 2014 01:34, Tudor Girba <[hidden email]> wrote:
|
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.
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
|
thanks I am already spread very thin and am reluctant to drop Pharo as I have no assurance that Dolphin Smalltalk is going to hang in there ... and I have health issues already in early retirement ( NOBODY even interviews a software developer over 60 in Canada - even though the Google guys I meet want me to keep their card ... but they FLY new grad's out to Mountainview ... - and then their are the customers who NEVER pay any bill before 90 days IF EVER. )On 27 February 2014 10:29, <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |