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

Groups > comp.sys.acorn.programmer > #247 > unrolled thread

Toggling an Icon on the bar

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

Contents

  Toggling an Icon on the bar Martin Hansen <mhh@shrewsbury.org.uk> - 2011-04-28 19:12 -0700
    Re: Toggling an Icon on the bar James Lampard <dontreplytothis@mailinator.com> - 2011-04-28 20:32 -0700
    Re: Toggling an Icon on the bar Martin Wuerthner <spamtrap@mw-software.com> - 2011-04-29 11:21 +0200
      Re: Toggling an Icon on the bar James Lampard <dontreplytothis@mailinator.com> - 2011-04-29 03:01 -0700
        Re: Toggling an Icon on the bar Martin Hansen <mhh@shrewsbury.org.uk> - 2011-04-29 03:15 -0700
          Re: Toggling an Icon on the bar Martin Wuerthner <spamtrap@mw-software.com> - 2011-04-29 12:38 +0200
            Re: Toggling an Icon on the bar Martin Hansen <mhh@shrewsbury.org.uk> - 2011-04-29 03:56 -0700
          Re: Toggling an Icon on the bar Steve Fryatt <news@stevefryatt.org.uk> - 2011-04-29 11:52 +0100

#247 — Toggling an Icon on the bar

Dear All,
I'm trying to toggle an icon on the icon bar so that it's
initially on the bar but then, when a 'hot key' is pressed
it is removed.
Press the 'hot key' again and it's back.

I've got the "hot key' part working. The icon goes on the
bar initially, fine. It deletes, OK.
I'm having trouble getting it back again after that.

I'm using Wimp_CreateIcon and Wimp_DeleteIcon.

To start with
DIM icon% 36

$icon% = "!MyTask"
blk%!0=-1 : blk%!4=0 : blk%!8=0 : blk%!12=68
blk%!16=68 : blk%!20=&B7002102 : blk%!24 = icon%
blk%!28 = -1 : blk%!32 =LEN($icon%)
SYS "Wimp_CreateIcon",,blk% TO MyTask%

gets the icon on the bar

blk%!0=-2 : blk%!4 = MyTask%
SYS "Wimp_DeleteIcon",, blk%
SYS "Wimp_ForceRedraw",-2

gets it off.

If I now re enter the first routine after the DIM
it does not like the line
$icon%="MyTask"

I'm puzzled ?
Surely the sprite is still available for me to place again
on the bar ?
Or has the delete removed it from the sprite pool ?

Any help appreciated as it's driving me nuts !

Regards,
Martin.

[toc] | [next] | [standalone]

#248

On Apr 29, 3:12 am, Martin Hansen <m...@shrewsbury.org.uk> wrote:
> Dear All,
> I'm trying to toggle an icon on the icon bar so that it's
> initially on the bar but then, when a 'hot key' is pressed
> it is removed.
> Press the 'hot key' again and it's back.
>
> I've got the "hot key' part working. The icon goes on the
> bar initially, fine. It deletes, OK.
> I'm having trouble getting it back again after that.
>
> I'm using Wimp_CreateIcon and Wimp_DeleteIcon.
>
> To start with
> DIM icon% 36
>
> $icon% = "!MyTask"
> blk%!0=-1 : blk%!4=0 : blk%!8=0 : blk%!12=68
> blk%!16=68 : blk%!20=&B7002102 : blk%!24 = icon%
> blk%!28 = -1 : blk%!32 =LEN($icon%)
> SYS "Wimp_CreateIcon",,blk% TO MyTask%
>
> gets the icon on the bar
>
> blk%!0=-2 : blk%!4 = MyTask%
> SYS "Wimp_DeleteIcon",, blk%
> SYS "Wimp_ForceRedraw",-2
>
> gets it off.
>
> If I now re enter the first routine after the DIM
> it does not like the line
> $icon%="MyTask"
>
> I'm puzzled ?
> Surely the sprite is still available for me to place again
> on the bar ?
> Or has the delete removed it from the sprite pool ?

Could it be due to the fact that the original icon is using the sprite
"!MyTask" and then when you re-create it you are using "MyTask"
instead?

--
James.
To reply use james underline lampard at talk 21 dot com

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

#249

In message <9330de2a-526b-4d39-b58f-2d389d8f02b9@k25g2000yqf.googlegro 
ups.com>
          Martin Hansen <mhh@shrewsbury.org.uk> wrote:

> To start with
> DIM icon% 36

> $icon% = "!MyTask"
> blk%!0=-1 : blk%!4=0 : blk%!8=0 : blk%!12=68
> blk%!16=68 : blk%!20=&B7002102 : blk%!24 = icon%
> blk%!28 = -1 : blk%!32 =LEN($icon%)
> SYS "Wimp_CreateIcon",,blk% TO MyTask%

"blk%!28 = -1" is not a good idea. There is no sprite area at -1.

> gets the icon on the bar

> blk%!0=-2 : blk%!4 = MyTask%
> SYS "Wimp_DeleteIcon",, blk%
> SYS "Wimp_ForceRedraw",-2

> gets it off.

> If I now re enter the first routine after the DIM
> it does not like the line
> $icon%="MyTask"

"Does not like" is not really a good description of a fault, in 
particular in a programmers' forum. How did you arrive at the 
conclusion that something does not like that line? Is there an error?

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

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

#250

On 29 Apr, 10:21, Martin Wuerthner <spamt...@mw-software.com> wrote:
> In message <9330de2a-526b-4d39-b58f-2d389d8f0...@k25g2000yqf.googlegro
> ups.com>
>           Martin Hansen <m...@shrewsbury.org.uk> wrote:
>
> > To start with
> > DIM icon% 36
> > $icon% = "!MyTask"
> > blk%!0=-1 : blk%!4=0 : blk%!8=0 : blk%!12=68
> > blk%!16=68 : blk%!20=&B7002102 : blk%!24 = icon%
> > blk%!28 = -1 : blk%!32 =LEN($icon%)
> > SYS "Wimp_CreateIcon",,blk% TO MyTask%
>
> "blk%!28 = -1" is not a good idea. There is no sprite area at -1.
>

According to PRM3-101 for an indirected sprite-only icon, the sprite
pointer should be +1 in order to use the Wimp sprite pool.

[snip]

--
James.
To reply use james underline lampard at talk 21 dot com

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

#251

On Apr 29, 11:01 am, James Lampard <dontreplytot...@mailinator.com>
wrote:
> On 29 Apr, 10:21, Martin Wuerthner <spamt...@mw-software.com> wrote:
>
> > In message <9330de2a-526b-4d39-b58f-2d389d8f0...@k25g2000yqf.googlegro
> > ups.com>
> >           Martin Hansen <m...@shrewsbury.org.uk> wrote:
>
> > > To start with
> > > DIM icon% 36
> > > $icon% = "!MyTask"
> > > blk%!0=-1 : blk%!4=0 : blk%!8=0 : blk%!12=68
> > > blk%!16=68 : blk%!20=&B7002102 : blk%!24 = icon%
> > > blk%!28 = -1 : blk%!32 =LEN($icon%)
> > > SYS "Wimp_CreateIcon",,blk% TO MyTask%
>
> > "blk%!28 = -1" is not a good idea. There is no sprite area at -1.
>
> According to PRM3-101 for an indirected sprite-only icon, the sprite
> pointer should be +1 in order to use the Wimp sprite pool.
>
> [snip]
>
> --
> James.
> To reply use james underline lampard at talk 21 dot com

Dear Martin and James,
Yes, I agree blk%!28 should be +1.
That is an error, although not the only thing wrong
as it does not fix the problem..

The error I get when it meets the line $icon%="!MyTask"
(second time around) is "abort on data transfer" at that line.

I've now got it working however by having a duplicate procedure with
DIM icon2% 36 etc with all references to icon% changed to icon2%.
This I can toggle as many times as I like, so I have a 'work around'.

Still curious, I've found that with a hack to let $icon% = "!MyTasak"
first time
and $icon% = any text string
the second time causes the error.

I don't know what that's telling me....

Regards,
Martin.

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

#252

In message <e26486bf-495f-48bc-a2f2-dcf4c21b066e@s4g2000yql.googlegrou 
ps.com>
          Martin Hansen <mhh@shrewsbury.org.uk> wrote:

> [...]

> The error I get when it meets the line $icon%="!MyTask"
> (second time around) is "abort on data transfer" at that line.

> [...]

> I don't know what that's telling me....

That is telling you that the value of icon% was corrupted, most 
probably because you used the same variable name for something else 
somewhere else in the program. Adding "*Report icon%" just before that 
line will tell you in an instant (using Martin Avison's Reporter - 
highly recommended).

For instance, a typical Mouse Event handler reads:

mouse_x% = blk%!0: mouse_y% = blk%!4: buttons% = blk%!8
window% = blk%!12
icon% = blk%!16

The last line corrupts your icon buffer pointer, so any attempt to 
write to the buffer afterwards leads to a data abort. Of course, the 
above handler should start with the line

LOCAL mouse_x%, mouse_y%, buttons%, window%, icon%

which helps avoiding clashes with global variables, but not fully, 
since any routine called from the handler still sees the local copy of 
the variable instead of the global one. So, to write reliable BASIC 
code, you should use some naming conventions, e.g., prefix every 
global variable with "g", so you have "DIM gIcon% ...", which avoids 
any clashes with local variables. This is even more important if you 
use libraries.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

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

#254

On Apr 29, 11:38 am, Martin Wuerthner <spamt...@mw-software.com>
wrote:
> In message <e26486bf-495f-48bc-a2f2-dcf4c21b0...@s4g2000yql.googlegrou
> ps.com>
>           Martin Hansen <m...@shrewsbury.org.uk> wrote:
>
> > [...]
> > The error I get when it meets the line $icon%="!MyTask"
> > (second time around) is "abort on data transfer" at that line.
> > [...]
> > I don't know what that's telling me....
>
> That is telling you that the value of icon% was corrupted, most
> probably because you used the same variable name for something else
> somewhere else in the program. Adding "*Report icon%" just before that
> line will tell you in an instant (using Martin Avison's Reporter -
> highly recommended).
>
> For instance, a typical Mouse Event handler reads:
>
> mouse_x% = blk%!0: mouse_y% = blk%!4: buttons% = blk%!8
> window% = blk%!12
> icon% = blk%!16
>
> The last line corrupts your icon buffer pointer, so any attempt to
> write to the buffer afterwards leads to a data abort. Of course, the
> above handler should start with the line
>
> LOCAL mouse_x%, mouse_y%, buttons%, window%, icon%
>
> which helps avoiding clashes with global variables, but not fully,
> since any routine called from the handler still sees the local copy of
> the variable instead of the global one. So, to write reliable BASIC
> code, you should use some naming conventions, e.g., prefix every
> global variable with "g", so you have "DIM gIcon% ...", which avoids
> any clashes with local variables. This is even more important if you
> use libraries.
>
> --
> Martin
> ---------------------------------------------------------------------
> Martin Wuerthner         MW Software      http://www.mw-software.com/
>         RISC OS Software for Design, Printing and Publishing
> ---------------------------------------------------------------------

Dear Martin,
You are right, of course.
This had occurred to me and I'd done a search on "icon%" and
still hadn't spotted it.... DUH!
Thanks for your help.
Yes, I need to start using !Reporter.....
I'll post the revised code on RISCOScode later today.
It's an update of the FREE !Mouser application.
Regards,
Martin.

http://www.RISCOScode.com

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

#253

On 29 Apr, Martin Hansen wrote in message
    <e26486bf-495f-48bc-a2f2-dcf4c21b066e@s4g2000yql.googlegroups.com>:

> The error I get when it meets the line $icon%="!MyTask" (second time
> around) is "abort on data transfer" at that line.
> 
> I've now got it working however by having a duplicate procedure with DIM
> icon2% 36 etc with all references to icon% changed to icon2%. This I can
> toggle as many times as I like, so I have a 'work around'.

That doesn't sound clever, as every time you toggle the icon you'll leak 37
bytes of memory...

> Still curious, I've found that with a hack to let $icon% = "!MyTasak"
> first time and $icon% = any text string the second time causes the error.
> 
> I don't know what that's telling me....

That either the value of icon% is being changed, or the memory that it
points to is becoming deallocated, between the two calls.  In BASIC, that
either means you're locally DIMming off the stack (this may not be possible
in all versions of BASIC) or you're changing the value of icon% somewhere
else between the calls.  You'll need to get to the bottom of why this is,
because it could have some much wider implications even with your
work-around (particularly if it's a LOCAL DIM issue, as the Wimp isn't going
to like that one much).

What is the value of icon% (ie. the memory address it points to) when you
write to it the first time, and then when you write again and it fails?

-- 
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

[toc] | [prev] | [standalone]

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

csiph-web