Announcing MacTasks - "To do" list for the classic Mac

[bigmessowires]

I don't think anybody in this thread has tried the app on real hardware, only emulation so far. So it's probably too soon to make any conclusions about whether the Time Manager countdown problem is specific to emulation. It would make sense if the problem is sensitive to how quickly the app runs through the dialog event loop, etc. If you're able to resolve the problems preventing the app from running under System 8 or System 7, I can try it on my PPC machine here.

 

[paws]

If you're able to resolve the problems preventing the app from running under System 8 or System 7, I can try it on my PPC machine here.

Beta 2 should already run, actually, at least it has worked for one person on 8.1 in emulation where it did not previously.

 

[bigmessowires]

Beta 2 works OK on my PowerMac 7100 with System 8.0. The countdown runs smoothly. One minor issue though: the default position of the registration dialog on a 640x480 monitor results in the bottom being cut-off. The dialog can't be repositioned, so there's no way to fit the whole thing on the screen. Fortunately enough of the buttons are still visible at the bottom edge of the screen so that you can click on them.

 

[paws]

They can. One shouldn't call toolbox routines that can move memory from timer routines, the results can be ... interesting. And the calls that change dialog box item texts move memory, quite aside from re-entrancy concerns. So yeah, @paws, I'd second @bigmessowires' suggestion - change a global variable, and use that in your main loop.

Just now returning to this, I've tried changing the code as you suggest, but I'm not sure how it's supposed to work. I'm using ModalDialog in a do-loop, and that blocks until an event happens, so I obviously can't update anything inside the loop. Is the solution to implement the "filterProc" and do it in there?

 

[bigmessowires]

It's been a very long time, but I think you can configure things such that you'll get nullEvents when there's no actual keyboard/mouse event, so your loop can do other processing and updates.

 

[paws]

Thanks for the pointer. I looked into null events, and I think they're actually enabled by default? At least they're not part of the event mask.

Anyway, I was a little puzzled (put off, TBH) by the amount of work that the documentation tells you to do when implementing an EventFilter procedure for ModalDialog... but it turns out I can just return false and everything goes to the default handler anyway? I'm not sure what I'm overlooking, but I can now update my dialog from inside the EventFilter and just return false indicating I didn't handle the event, and I have working copy and paste and everything - so why does the documentation suggest I reimplement it? Toolbox is confusing!

I also reinstalled CodeWarrior last night so I now at least have a functional 68k compiler. I haven't got MacZoop to compile yet, though.