Notifications and Scheduler

Sheppy

unread,

Mar 25, 2013, 8:08:57 PM3/25/13

to

If I'm using Scheduler to run code that needs to run at a tricky time
(it's invoked in response to a GS/OS notification proc), how can I
safely display a dialog box to ask the user a question? I'm trying to
figure out how to deal with a situation where something needs to be
confirmed to prevent an accidental loss of data under this circumstance.

Right now, my Scheduler task is locking the GS up good and solid when I
try to do my UI. I've tried an old fashioned Dialog Manager dialog box
and an AlertWindow both, and both lock up.

I've tried just calling GetNextEvent to see if that's hanging things,
and it's not the culprit.

Any thoughts?

--

Eric Shepherd (Sheppy)
http://www.sheppyware.net

Sheppy

unread,

Mar 25, 2013, 8:41:26 PM3/25/13

to

On 2013-03-26 00:08:57 +0000, Sheppy said:

> I've tried just calling GetNextEvent to see if that's hanging things,
> and it's not the culprit.

I guess I'm going to have to figure out another approach to this whole
thing... even TLMountVolume locks up, and that works from code poked
into memory and called from Applesoft. :)

Sheppy

unread,

Mar 31, 2013, 10:05:15 AM3/31/13

to

On 2013-03-26 00:41:26 +0000, Sheppy said:

> I guess I'm going to have to figure out another approach to this whole
> thing... even TLMountVolume locks up, and that works from code poked
> into memory and called from Applesoft. :)

For what it's worth, in case anyone has been following along, I've
found that having my Scheduler task set some things up, then set a
flag, and having a SystemTask patch watch for that flag to be set and
then start my work up including the UI stuff, works just fine.

Eric Shepherd

unread,

May 9, 2013, 6:31:21 AM5/9/13

to

I just came up with an idea. I'm going to patch SystemTask. I'll set a flag
instead of creating a Scheduler task, and my SystemTask patch will check
the flag. When it's set, I do my alert and other processing. Should work
like a charm, since SystemTask is called right before asking DAs to do
their UI processing.

Yay hacky patching goodness! I'll report back and let y'all know if it
works. :)

Bill Buckels

unread,

May 9, 2013, 8:26:04 AM5/9/13

to

"Eric Shepherd" <she...@sheppyware.net> wrote:
> Yay hacky patching goodness! I'll report back and let y'all know if it
> works. :)

Thnaks Sheppy, but to me (the relatively uniniated Apple //e guy with the
Orca Compiler and GS gathering dust in the corner) this sounds like a
desperate measure if you plan to distribute your product once done. Does
this mean that your installer will need to patch the GS/OS system for your
product to work?

I used to write MS-DOS interrupt driven TSR's in the 80's but when Windows
3.1 became popular in 1992 I had no problem writing schedulers that were
compatible without patches.

I had a GS for testing my Apple //e programs back then but never got into
it, so I am trying hard to understand why the patch would necessarily be a
good solution.

Is there any way to educate me? I was a little alarmed to see your original
post on this. My thoughts were "If Eric doesn't know, then who does?"

Or am I just confused:)

Bill

Eric Shepherd

unread,

May 11, 2013, 7:50:04 AM5/11/13

to

"Bill Buckels" <bbuc...@mts.net> wrote:
> "Eric Shepherd" <she...@sheppyware.net> wrote:
>> Yay hacky patching goodness! I'll report back and let y'all know if it
>> works. :)
>
> Thnaks Sheppy, but to me (the relatively uniniated Apple //e guy with the
> Orca Compiler and GS gathering dust in the corner) this sounds like a
> desperate measure if you plan to distribute your product once done. Does
> this mean that your installer will need to patch the GS/OS system for your
> product to work?

No no... this is a common procedure, and it's even documented in the
Toolbox Reference manuals. It's done in memory by patching the call tables
for a tool set when your code runs. No need for an installer or permanent
patches to the operating system.

Sheppy

Bill Buckels

unread,

May 11, 2013, 9:55:11 PM5/11/13

to

"Eric Shepherd" <she...@sheppyware.net> wrote:

>No no... this is a common procedure, and it's even documented in the
>Toolbox Reference manuals. It's done in memory by patching the call tables
>for a tool set when your code runs. No need for an installer or permanent
>patches to the operating system.

Thanks for taking the time to clarify. Not that I'll be joining you anytime
soon. I'm still happily working my way through DOS 3.3 and ProDOS 8 on my
//e, so my GS and Orca C remain untouched...

Bill