John M McIntosh wrote:
> This fails on windows VM
>> StandardFileStream forceNewFileNamed: 'ConflictChecker.log'.
>> if you invoke in SystemDictionary>>send: toClassesNamedIn:with:
> at startup time
>> but it works on mac/linux
>> after all startup runs then
>>> StandardFileStream forceNewFileNamed: 'ConflictChecker.log'.
>> works on windows
>> why it fails is a bit hard to track since the failure results in a image
> Ui that does not respond to keyboard, clicks etc.
>> No doubt it is because FileDirectory>>startUp has not run yet.
Right. So why is this a Windows VM issue? Perhaps you should call
FileDirectory startUp before doing file operations?!
> Of course what I'm tracking is why my WikiServer image does not show the
> window when you start it.
> Attempting to add the traceing to log file, which then causes the
> walkback then does show the window.
>> I'm sure at some point here I'll get far enough along to see what window
> specific behaviour is causing failure in the startup: processing.
My suspicion would be that this is because you saved the image on
Mac/Unix thus the ActiveDirectoryClass is set to UnixFileDir and
consequently fails on Windows. If you'd save the image on Windows it
will likely show the same behavior on Mac/Unix. I still fail to see what
this has to do with the Windows VM - file and directory operations
*will* fail if unless you call FileDirectory>>startUp.
Cheers,
- Andreas