Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #688 > unrolled thread

Notifications and Scheduler

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Notifications and Scheduler Sheppy <sheppy@sheppyware.net> - 2013-03-25 20:08 -0400
    Re: Notifications and Scheduler Sheppy <sheppy@sheppyware.net> - 2013-03-25 20:41 -0400
      Re: Notifications and Scheduler Sheppy <sheppy@sheppyware.net> - 2013-03-31 10:05 -0400
    Re: Notifications and Scheduler Eric Shepherd <sheppy@sheppyware.net> - 2013-05-09 10:31 +0000
      Re: Notifications and Scheduler "Bill Buckels" <bbuckels@mts.net> - 2013-05-09 07:26 -0500
        Re: Notifications and Scheduler Eric Shepherd <sheppy@sheppyware.net> - 2013-05-11 11:50 +0000
          Re: Notifications and Scheduler "Bill Buckels" <bbuckels@mts.net> - 2013-05-11 20:55 -0500

#688 — Notifications and Scheduler

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

[toc] | [next] | [standalone]

#689

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. :)

-- 

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

[toc] | [prev] | [next] | [standalone]

#694

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 (Sheppy)
http://www.sheppyware.net

[toc] | [prev] | [next] | [standalone]

#719

Sheppy <sheppy@sheppyware.net> wrote:
> 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?


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. :)

[toc] | [prev] | [next] | [standalone]

#720

"Eric Shepherd" <sheppy@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

[toc] | [prev] | [next] | [standalone]

#721

"Bill Buckels" <bbuckels@mts.net> wrote:
> "Eric Shepherd" <sheppy@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

[toc] | [prev] | [next] | [standalone]

#722

"Eric Shepherd" <sheppy@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 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web