"Raab, Andreas" wrote:

> Edward,
>
> [Note: I'm writing this reply at home so I can't check anything out]
>
> > My z50 has the standard 16MB memory, and I loaded WinCE
> > Squeak into a 32MB CF card. When I start Squeak, it prompts
> > for an image file, then announces it can't *find* the source
> > at <pathname which is exactly where the source should be>.
> > Not a real problem, but I would like to do some real
> > development on this machine, and eventually want to use
> > the sources.  Does it not find the source,
> > or is it that memory is too small to map it all in?
>
> It *probably* does not find the source. There is no attempt to actually map
> the entire sources file into memory (which would be a ridiculous attempt on
> this machine anyways ;-) I'll have a look at it tomorrow but if Squeak does
> not complain about the changes file then there is obviously some problem
> with the sources file itself. Ah ... that reminds me of something: Flashcard
> quality. It could be possible that the flash card has a read error when
> Squeak attempts to open the source file and this would probably be reported
> as a missing sources file. You might try to view the sources file in the
> file list and see if that works. If not, it's likely to be the flashcard.
>

I looked around for the CE sources and found a 2.2 version, and lo and behold
(to my embarrassment) I found the README, which says that the logic for reading
in the source file was never implemented.  My flash cards are quite good - after
all, the Squeak executable and image live there and they've never crashed!

As far as the changes file, an error window comes up (UndefinedObjects are not
indexable) during the execution of FileDirectory
class>>openSources:andChanges:forImage: (when it tries to open the source file),
so it never even tries to open the changes file after I dismiss the error
window.  fullname: prepends a "\S" onto the actual full file path, and I don't
know whether this is correct for CE, but if not, I can see why the file can't be
found.  Further down in StandardFileStream class>>readOnlyFileNamed:  it sends
fullname: again, but by then the parameter is nil.  Another thing to consider is
that the full file path has a space character in it - the flash card has a fixed
name of "Storage Card" - and I don't know if this is accptable to
DosFileDirectory.

The README pretty much describes the rest of the problems as well.  Dean Swan
was kind enough to send me email that notes that my problems are not unique and
that no one has the time to fix them.  I can live with that because most of the
system works adequately.  But without the sources, it will be awkward to submit
CE bug fixes or goodies to the community as changesets.

>
> > Only the left mouse button works. What I mean by an input
> > handler is the piece of  platform-specific code that actually
> > collects input events on behalf of the interpreter.
> > Currently, it seems to assume a touchscreen, which has no
> > buttons, no pointer, no "clicking" (mouse-down / mouse-up)
> > events.  There must be a way to distinguish between a touchscreen
> > and a mouse, and then "do the right thing".
>
> Strange ... IIRC, this actually worked on our machine. We had no problems to
> play around with most stuff including Morphic and the Scripting system
> (e.g., drag and drop, painting, and similar actions).
>

Morphic is a lot of fun on this machine - it's slow, but if I added memory and
ran it out of the RAM disk it would probably be a lot faster.  The ST-80
interface is fast, but not as much fun.

>
> > Although I can use Alt-Left Button to bring up an action menu
> > for selected text, why not the right button?  Neither I nor Blair
> > know (yet) how to emulate the middle button.
>
> We noticed some problems with reporting some of the special keys like Alt. I
> will have to check this out.
>

I meant the right MOUSE button doesn't work (I can see the ambiguity) - however,
just seconds ago I tried the right-hand ALT key and it didn't work either.

>
> > As far as the cursor problem, it never changes into a
> > scribbling pen or pair of glasses or funny little ST-80
> > scrollbar arrows, so I can't tell if it's thinking or dead,
> > or what direction it will scroll in.  It's just a big fat
> > Microsoft arrow that covers up too much real estate.
>

Dean Swan is working on a software cursor that will do the trick, but he's
busy.  He offered it to me, but I don't have the development tools, and am
disinclined to buy them since my main focus is on the EPOC port.  There probably
should be a way inside Squeak to substitute an appropriate hardware cursor for
any of the Squeak cursors (especially using a built-in wait cursor for any long
operations, like saving the image).  I bet EPOC has the same problem, so I will
add a sqEpocWaitCursor primitive, a new preference and some class modifications
to make it work (unless there is a simpler way).

>
> That's true. I believe that this behavior originates back to Blair's
> original port (which was supposed to be for WinCE 1.0) and older versions of
> WinCE did not support any cursor except the arrow and the wait cursor. Seems
> like it's time to fix this.
>
>   Andreas