Magsbot Class, Session 6
Saturday April 1, 2006 6pm VRT
Magine:
hi all
Belle. Thavas:
Hi Magine :-)
Belle. Thavas:
looks like I'm it so far
Belle. Thavas:
how's your back today?
[Mags]: That's
Belle. Thavas (27529).
Magine: ok for
the moment...
Belle. Thavas:
I hear ya...a respite, not a cure
Guri Lady: I'm
here was looking at my emails :)
Guri Lady:
Hello, Magine :0
Guri Lady:
Hello, Belle
Guri Lady:
*hugs*
Belle. Thavas:
Hi Guri Lady :-)
[Mags]: That's
Belle. Thavas, cit 344784, IP 0.0.0.0
Belle. Thavas:
Well, as you know, Magine, I tried the @objinzone_rel[name] as an
expression and the proggy didn't like that
[Mags]: That's
[Hervey], cit 0, IP 0.0.0.0
Belle. Thavas:
I didn't get a chance to try again do to being out of it, myself
Magine: i tried
it this morning, it does work...
Belle. Thavas:
I didn't confirm with you if I put the macro in properly in the udf file
[Mags]: That's
[Hervey], cit 0, PID 344784, IP 0.0.0.0
[Mags]: That's
Belle. Thavas, cit 344784, PID 344784, IP 0.0.0.0
Belle. Thavas:
what I did was make a backup copy, then removed the old macro line and
put in the new one, saved file.
Magine: removed
the old one?
Belle. Thavas:
there was already an @objinzone line in the file
Magine: you
could have just added the new one, they have dif names
Magine: old =
@objinzone
Magine: new =
@objinzone_rel
Belle. Thavas:
I tried it that way too
Belle. Thavas:
leaving it in active
Belle. Thavas:
leaving it in commented out
Belle. Thavas:
removing it altogether
Belle. Thavas:
but I'll have another go this week
Magine: you can
have both in there, should be no problem
Belle. Thavas:
maybe I was just too run down
Belle. Thavas:
ok
Belle. Thavas:
oh, and I still need to check the "relative to origin" box?
Magine: right
Belle. Thavas:
ok
Magine: and use
@objinzone_rel instead of @objinzone, in the conditional expression box
Magine: also,
you remember when you make changes to the .udf file, you need to reload
that file or else restart the bot
Belle. Thavas:
I considered that and I believe I did restart it, but I'll see how it
goes from here on out
Belle. Thavas:
today is the anniversary celebrations in Arcadia
Belle. Thavas:
I wonder if some of the classmates related to that world are busy this
afternoon
Magine: maybe...
Belle. Thavas:
What was today's topic to be?
Magine:
continuing where we left off with the behavior table...
Belle. Thavas:
ok
Magine: any
questions from last time?
Belle. Thavas:
I'm still catching up. I'll have had a chance to go through all the
exercises from last week by midweek.
Magine: ok
Magine: i guess
i need to glance at the log myself, to see where we left off
Belle. Thavas:
I think I just shut down last week, had no energy for much of anything
Magine: the way
i feel today :D
Belle. Thavas:
hehe..
Magine: must
have been that april fools joke of AW :P
Belle. Thavas:
haha, yes...
Magine: has
everyone downloaded their new 4.1 AWB? :D
Belle. Thavas:
were you here earlier when it looked like they had the water level set
waste high?
Guri Lady: nope
Magine: no i
didn't see that
Guri Lady: me
either
Belle. Thavas:
I think it went away more than an hour ago
Guri Lady: lol
Belle. Thavas:
but my av was standing here wading
Guri Lady: but
that was annoying hehe
Belle. Thavas:
yep, esp as there was no texture, so it was just this whiteness
Magine:
(looking at the class schedule) hm, i don't think i have stuck to it
very well....the next 2 classes after this are about buttons, but we
already did much of that
Guri Lady: Yep
:)
Magine: ok, i
know....we should discuss some of the special commands used in the BT
to determine which rows are checked
Belle. Thavas:
yeah, buttons seem pretty clear
Belle. Thavas:
ok
Magine:
so......as you should already know, when an event occurs, like someone
chatting or moving or whatever, the bot gets a message from the world
server
Magine: and if
the BT is active (menu Options/Behavior Table Active checked)
Magine: then
the message is sent to the BT along with the relevant data for that
kind of event
Belle. Thavas:
ok
Magine: then,
each row of the BT that has an event of that type, for example HEAR if
it was a chat event, is checked to see if the conditional expression in
the event column is true or not
Magine: and if
the expression is true (anything other than 0, that is) then the action
on that row is triggered
Magine: but,
after that action is triggered, magsbot continues to check the rows of
the BT that follow that one
Belle. Thavas:
ok
Magine: so any
row with a matching event type and conditional expression that is
non-0, are also triggered
Magine:
however, sometimes you might not want that
Magine: and if
that's the case, then you can put the ENDCHECK command in the action of
a BT row,
Belle. Thavas:
ahhh ok
Magine: and no
futher rows will be checked, IF the action in that row was triggered
Belle. Thavas:
great, ok
Magine: another
way of controlling that is,
Magine: you can
use the ENDONREACT command,
Magine: which
has the same effect as automatically doing and ENDCHECK in all the rows
that follow
Magine:
actually the command is ENDONREACT 1 to turn that on, or ENDONREACT 0
to turn that off
Magine: so
basically, ENDONREACT 1 reverses the normal method
Belle. Thavas:
ok
Magine:
normally magsbot continues to check rows unless there is an ENDCHECK,
Magine: but
when you start ENDONREACT 1 then magsbot stops checking rows after the
first row that is triggered
Magine: *when
you state ENDONREACT 1, i meant to say
Magine: and the
same way that you can use ENDCHECK to cause checking to stop at a
particular row when ENDONREACT is off,
Belle. Thavas:
checking something..
Magine: you can
use CONTCHECK to override the ENDONREACT 1 and *continue* checking past
that one row, when ENDONREACT is on
Magine: i hope
that makes sense...it sounds confusing even to me :D
Magine: but
it's actually pretty simple
Belle. Thavas:
THe ENDCHECK goes at the end of the action line of the row?
Magine: but it
allows you to set up elaborate circumstances for what rows get checked
and when
Magine: it
doesn't need to, belle....and ENDCHECK command that is executed
anywhere within the action, will stop checking after that row
Belle. Thavas:
ahh ok...as I can't seem to get to the end of a row :-)
Magine: so
another way of putting it is, ENDONREACT sets the default method, and
ENDCHECK and CONTCHECK explicitly force a particular method for just
that row
Magine: oh
btw...don't confuse ENDCHECK with the BREAK command
Belle. Thavas:
ok
Magine: BREAK
causes the execution of an action to end at that point
Belle. Thavas:
gotcha
Magine: but
doesn't affect the checking of further rows
Belle. Thavas:
makes sense
Magine: so for
example, if you have IF @somevariable { REPORT "foo!"; BREAK };
REPORT "fee!"
Magine: then if
@somevariable was true (non-0) then the bot would print foo! in the
chat window, but not "fee!" because the BREAK ended execution
Guri Lady:
sorry my kid stayed home today and he's giving me problems
Guri Lady:
*sighs*
Guri Lady: brb
again
Magine: but if
@somevariable was false (0) then "fee!" would print becauise the BREAK
wouldn't be called
Magine: k, guri
Belle. Thavas:
right, got it
Magine: now i
said before that each row of the BT is checked only for the particular
event,
Magine: that
is, for a HEAR event it won't even look at rows with, for example,
AVATARCHANGE
Magine: but
there is one exception: the ANY event
Magine: a row
with ANY will always be checked for any event type (unless a ENDCHECK
or ENDONREACT 1+triggered row stopped the checking before it got there)
Magine: so, to
further complicate matters :D that gives you yet another way to
control checking, by using the CHECK command
Belle. Thavas:
haha ok, I got it..
Magine: the
CHECK command turns checking on or off, sort of
Magine: when
you have CHECK 0 (checking turned off), magsbot will actually still
check the appropriate rows, but it won't react to them, an action will
not be triggered
Belle. Thavas:
can you give us examples of how these are used in practical terms?
Magine: yep,
coming the that
Belle. Thavas: k
Magine: so,
suppose you wanted to put some rows in the BT that would only be
checked for one particular bot instance
Magine: if you
were running several bot instances
Magine: what
you could do is,
Belle. Thavas:
ok, cool, I'm running two now, in fact
Belle. Thavas:
one here and one in OW
Magine: at the
beginning of that section, you could put an ANY event, with CHECK
@eq[$botname,Atuin]
Magine: as the
action
Magine: if the
bot instance is named "Atuin" then the following rows will be checked,
Belle. Thavas:
ahhhh
Magine: but if
the bot instance has any other name, the following rows will not be
checked
Magine: then at
the end of the section that you wanted to be used only by a particular
instance,
Magine: you
could put another ANY event and CHECK 1, so the rows farther down would
get checked again
Magine: because
another peculiarity of the ANY event is that it always gets checking,
even if checking is turned off by a CHECK 0 command
Belle. Thavas:
ok
Magine: so
there is a practical example of ANY...CHECK
Belle. Thavas:
great, thanks!
Magine: an
example of ENDCHECK might be if you have a whole list of rows like HEAR
@cmd_[somecommand]
Magine: you
could put the more command commands at the top (higher row)
Magine: and put
ENDCHECK in each row,
Magine: so that
once magsbot finds a row that matches what was heard, it will stop
checking there....no need to examine the following rows
Belle. Thavas:
ok
Magine: or,
instead of putting ENDCHECK in each row, you could just put a HEAR
event with ENDONREACT 1 as the action,
Magine: and any
row past that one that is triggered, will end the checking
Belle. Thavas:
nice
Magine: the
ENDCHECK, CONTCHECK, ENDONREACT commands all override the ANY..CHECK
stuff
Belle. Thavas:
ok
Magine: another
thing to undestand, is that ENDCHECK or CONTCHECK set a flag that won't
be changed by another call to those commands in the same action
Magine: so you
could not, for example, put ENDCHECK at some point in the code and then
put CONTCHECK further down to cancel it....
Belle. Thavas:
ahhhh
Magine:
whichever of those two commands you call within a given row will be set
Belle. Thavas:
good to know, ok
Belle. Thavas:
so, don't use those unless you really mean it
Magine: right
Magine: so does
that all make sense to "everyone" (all 2 of you, heheh)?
Belle. Thavas:
ok, for that situation..
Magine: yes?
Belle. Thavas:
could you then switch to CHECK or HEAR?
Belle. Thavas:
or just not set it up that way
Magine: not
sure what you mean....HEAR is an event, CHECK is a command
Belle. Thavas:
or then CHEK
Belle. Thavas:
CHECK..
Belle. Thavas:
say you do the ENDCHECK...
Magine: yes
Belle. Thavas:
then on would CHECK resume it?
Magine:
no....like i said, the ENDCHECK/CONTCHECK/ENDONREACT override the CHECK
command
Belle. Thavas:
that's right, sorry
Magine: once
you issue a ENDCHECK, it is all over :D no rows past that will be
looked at
Belle. Thavas:
lol
Belle. Thavas:
yeah, ok just being sure
Magine: or if
you have ENDONREACT 1, then no rows will be checked after the first row
that is triggered
Belle. Thavas:
ok
Magine: but by
comparision, the CHECK can be turned back on
Magine: CHECK 0
in one row's action to turn it off, then CHECK 1 in another row's
action to turn it back on
Belle. Thavas:
gotcha yes
Magine: with
the "catch" being that, when you do CHECK 0, no rows are going to be
checking except the ANY rows
Magine: so once
you use CHECK 0 to turn checking off, if you want to turn it back on,
it must be in a row with an ANY event,
Magine: because
rows with any other event besides ANY, won't be checked
Belle. Thavas:
oook...
Magine: i hope
that isn't too confusing...
Belle. Thavas:
not confusing, just a detail to be aware of
Belle. Thavas:
the use of all of this..
Belle. Thavas:
is this best served for creating rpg bots...or what other uses?
Belle. Thavas:
you mentioned the bot instance one, so that made me wonder
Magine: well,
whatever you can think of :) the basic use of it all, is to have
sections of the BT that are only used under certain circumstances, like
only by certain bot instances, or any other conditions you can think of
Magine: you
might want to have a section of the table that you can turn on or off
by setting a global variable
Belle. Thavas:
so this one table can be developed into sections per bot....
Belle. Thavas:
ok
Magine: so you
could have an ANY event and CHECK @gv_[UseSectionA] at the start of a
special section, and ANY ... CHECK 1 at the end
Magine: then
you could turn that section on simply by setting the global
@UseSectionA=1 or turn it off using @UseSectionA=0
Belle. Thavas:
hmmmm
Magine: it's
really however you can think to use it....
Belle. Thavas:
ok
Magine: BTW
that @gv_ function i used in the example, is a way to get the value of
a global variable without causing an error if the variable doesn't exist
Magine: i could
have put instead, CHECK @UseSectionA
Magine: but
then if the @UseSectionA variable didn't exist, that would cause an
error message
Belle. Thavas:
ahhh ok good to know
Magine: but the
@gv_ function will just return 0 if the variable doesn't exist, with no
error message
Belle. Thavas:
amazing...
Magine:
similarly, the $gv_ function will just return a blank if a global
string variable doesn't exist
Belle. Thavas:
I don't even want to think about the hours you spent designing all of
this *shakes head*
Belle. Thavas:
ok
Magine: well it
wasn't all in one sitting, that's for sure :D
Belle. Thavas:
lol, I bet not
Magine: and i
have added things as they were needed for various things, too
Magine: so some
of these ideas i didn't think of myself at first
Belle. Thavas:
understood
Belle. Thavas:
users develop needs and you add things
Magine: yup
Belle. Thavas:
what I was wondering is..what would happen if there was more than one bt
Belle. Thavas:
or a main bt and sub bt's...
Magine: well,
each bot instance receives it's own events
Magine:
therefore, the BT is checked separately for each instance
Magine: if two
instances both hear the same chat, the BT will be checked once for each
instance
Magine: that's
where you could use ANY ... CHECK with the bot's name, to ensure that
each instance would only use part of the BT (if you wanted that)
Belle. Thavas:
the one check covering both instances..
Magine: ummm,
no....
Belle. Thavas:
ok
Magine: well
yeah :D
Magine: that
is, the one CHECK command in the table would be used by both instances,
yes
Magine: if
that's what you meant
Belle. Thavas:
gotcha ok
Belle. Thavas:
yes
Belle. Thavas:
ok, so that would be a good reason to use the bot name
Magine: but
each instance would evaluate the CHECK command separately
Belle. Thavas:
right
Magine: using
the name would be one way...or you could set a different note in the
instance list for each bot instance, and use that
Belle. Thavas:
so, like I"m set up now, one in each uni, is not an issue
Magine: one
instance period, is not an issue
Magine: but if
you have multiple instances, even in dif universes, they will each
check the BT separately
Belle. Thavas:
I'll experiement with running more than one in the same vicinity then
:-)
Magine: this
kind of leads into the matter of instance handlers....
Belle. Thavas:
ok
Magine: and how
bots work generally, in terms of getting events from the world server
Belle. Thavas:
I noticed that the instance I'm running here has a number name assigned
to it, as it was the second one I started
Belle. Thavas:
using the same bot name
Magine: a
number name?
Belle. Thavas:
well, it appears as [Hervey]20791456
Magine: that's
the instance number
Belle. Thavas:
the first one is just [Hervey]
Magine: hmmm
Magine: no,
every instance has a number
Magine: you see
this number in the log, you mean?
Magine: or
where?
Belle. Thavas:
but the first one does have an instance number in the log
Belle. Thavas:
no, on my taskbar
Magine: ok i see
Belle. Thavas:
the two instances are differentiated
Belle. Thavas:
by one of them including the number next to the name
Magine: all
instance have an instance number, but if there is only one running, the
instance number just isn't shown
Magine: when
you have multiple instances then the number is shown so you can tell
them apart
Magine: but the
instance number will always show in the instance list (alt-I)
Belle. Thavas:
I'm thinking it didn't show the number for the first one because it was
first
Belle. Thavas:
yes, it's in the list
Belle. Thavas:
just the way it's being registered at the top left of the screen is
different in each
Magine:
whichever instance is selected in the instance list, is the "active
instance" that receives manual button clicks or commands typed in the
command window (F5)
Belle. Thavas:
ahhhh ...let me try that
Magine: and the
active instance is the one whose number shows on the program title bar
Magine: once
you have 2 instances going, you will see the number on the title bar as
you switch between them
Belle. Thavas:
yep that did it haha
Magine: when
you create an instance in the SDK, you get a "handle" that is actually
a memory address
Belle. Thavas:
ok...thought it was something more cryptic hehe
Magine: and
magsbot uses the handle as a numeric ID
Belle. Thavas:
ok
Magine: since
it is guaranteed to be unique
Magine:
so.....as long as we are talking about events....let's me briefly talk
about event handlers
Belle. Thavas:
which is good if one is going to run several
Magine:
yep,soyou can tell them apart in the task bar
Belle. Thavas:
is there a way to override those numbers to name them to some device
that would help you remember which bot is for what?
Belle. Thavas:
if using the same bot name
Magine: well,
you can put a different note on the instance list
Magine:
remember you set the note for an instance by using the INSTNOTE command
Belle. Thavas:
like [Hervey](garden) [Hervey](lake)
Magine: right
Belle. Thavas:
ahhh
Magine: well it
won't show as part of the name, it will show as the note in the
instance list
Belle. Thavas:
ok
Magine: so you
could select one of the bots in the isntance list then press F5 and
type INSTNOTE @instance "(garden)"
Belle. Thavas:
okies
Magine: then
select the other bot and press F5 and type INSTNOTE @instance
"(lake)" etc
Magine: you
could type the actual instance number instead of "@instance" but
@instance is simpler of course
Belle. Thavas:
yeah
Magine: what
you could do is, create a different button to start each bot, and then
edit the button and set a different note in there
Belle. Thavas:
I think I'm going to be a button person
Magine: start
the instance up, click "Create Instance Button", then after the button
is created, right-click it choose Edit, then add the INSTNOTE @instance
"somenote" to the button
Belle. Thavas:
cool
Magine:
so....getting back to handlers.....
Magine: when a
bot program calls the SDK function that gets messages from the world
server, the SDK function then calls the event handlers that have been
defined in the program
Magine: in the
case of magsbot, each event handler puts the relevant data into a
queue, and sends it to the BT in the order that the event occurred
Belle. Thavas:
ok
Magine: that is
the event queue that you can see on the monitor bar at the bottom of
the magsbot window (ctrl-M to open/close that bar)
Magine: the
thing is, when the SDK function is getting messages from the world
server, the program can't do anything else
Magine: because
the SDK function has taken control
Magine: so
magsbot continually switches between brief calls to the SDK function to
get messages, what i call "wait phase"
Magine: and
then actually responding to the events and sending them to the BT from
the queue, what i call "processing phase"
Magine: you can
adjust the timing of these two phases using the SYNCHTIMER command
Belle. Thavas:
ok
Belle. Thavas:
I recall you talking about wait and process but this breaks it down more
Belle. Thavas:
ok
Magine: the
default is SYNCHTIMER 100 500..that is, 100 ms spent getting messages,
and 500 ms (half second) spent reacting to them
Belle. Thavas:
ok
Magine:
actually the processing phase may last longer if a particular action is
very lengthly
Magine: each
processing phase, at least one action (one line of code in an action
sequence) is processed, and maybe more if there's time
Belle. Thavas:
and if you don't set it long enough, what tends to happen?
Magine: well
since at least one action will be processed each processing phase, then
setting that too short won't lock things up, but it will cause the
event queue to grow because it's full of unprocessed events
Magine: so the
response time of the bot will lag
Belle. Thavas:
ok
Magine: that
will also happen if you make the message-fetching "wait phase" too long
Belle. Thavas:
ok
Magine: but
there are some circumstances when it's helpful to have a longer wait
phase
Magine: for
example, when magsbot does a survey, if "high speed" is checked,
Magine: then
the timing will be automatically, temporarily changed to 1000 ms for
fetching events and a short time for processing
Magine: during
a survey, each object that is surveyed is an event,
Magine: so
having a longer wait phase means getting more objects surveyed for each
message-fetching phase
Belle. Thavas:
ahhh ok
Magine: you can
also turn off message fetching entirely, and handle it manually
Magine: the
SYNCH command turns "synchronous mode" on or off
Belle. Thavas:
ok
Belle. Thavas:
I was also wondering if
Magine:
synchronous mode means you have to fetch messages manually using
program code, so normally that is OFF.....
Magine: normal
mode is asynchronous
Belle. Thavas:
making a button or two with longer and shorter setups that I could
invoke for specific projects would work
Magine: when
you are in synchronous (manual) mode, you have to get messages using
the WAIT command
Belle. Thavas:
I'm sure for someone that option of synchronus mode wold come in handy
Magine:
actually i've never found a use for synchronous mode myself, :D
with one exception....
Belle. Thavas:
ahh one!
Magine: you can
reload the BT orbuttons without having to shut down magsbot,
Belle. Thavas:
ok
Magine: and you
can reload the macros file without having to shut down,
Belle. Thavas:
aha....
Magine: but if
you get messages while magsbot is reloading and it tries to
respond....it can cause problems
Belle. Thavas:
so best not to go there
Magine: well
you just have to take the precaution of pausing the messages while you
reload,
Magine: by
using the SYNCH 1 command to turn the synchronous mode on....when thats
on, the world server will hold the messages for you, for a SHORT time
(a few seconds)
Magine: take a
look in the "reload behavior & buttons" button on the . tab
Magine: if
nothing much is going on around your bot, you could just reload the BT
or buttons using the File menu,
Magine: but (as
with the RPGbot) you have a lot of stuff going on,
Belle. Thavas:
right
Magine: you
would use the "reload behavior & buttons" button,
Magine: so that
messages would be put "on hold" for a few seconds
Magine: you'll
also notice the use of the ENQUEUE command in that button there
Magine: that
puts the code into the action queue, which is a separate queue from the
event queue
Magine: any
guess as to why that is done? :)
Belle. Thavas:
haha hold on.. I'm still recovering from actually hitting the button
hehe
Magine: here's
a hint, itwould be especially important if that button was called using
CLICKBTN from the BT
Magine: heheh ok
Magine: anyway,
the reason for using ENQUEUE is so the code there isn't being run from
inside a button that might be replaced when the buttons are reloaded
Belle. Thavas:
ok, so that whole thing is in the action queue
Belle. Thavas:
as backup?
Magine: putting
commands in the action queue is a way to execute those commands, so
they aren't happening inside a button or the BT
Magine: you can
also use the action queue to "schedule" actions to run after a pause,
without having the pause take place in the BT where you want the action
to be handled quickly so it doesn't delay processing of events
Magine: for
example, suppose you want the bot to say something, pause a few
seconds, then say something else
Magine: in
response to some event
Belle. Thavas:
ok
Magine: you
*could* put SAY "first phrase"; MBWAIT 2000; SAY "second phrase"
in the action column of the behavior table
Magine: but
that would not be a good idea, because while the BT is doing stuff,
everything else is waitng for that event to be processed and finish
Magine: and the
MBWAIT 2000 would cause a two-second pause
Magine: so
instead, you would put
Magine: ENQUEUE
{ SAY "first phrase"; QWAIT 2000; SAY "second phrase" } in the behavior
table
Magine: so when
the action executes, instead of waiting around, it just puts those
actions into the action queue
Belle. Thavas:
wow, ok
Magine: then
after the BT has finished processing things, the code is run from the
action queue instead
Belle. Thavas:
interesting
Magine: and the
QWAIT command, instead of holding everything up, just waits for 2000 ms
before it performs the next command in that sequence
Belle. Thavas:
ok, great
Belle. Thavas:
that makes sense
Magine: in
other words, the say "first phrase" is executed, then the action queue
passes control back to the main program until the 2000 ms wait is up,
Magine: and
does the SAY "second phrase" on another cycle
Magine: so
anyway,the bottom line thing to remember is, if you don't want to tie
things up, you can put commands into the queue instead, to happen later
Belle. Thavas:
good thinking
Magine: i use
the action queue a lot with the RPGBot, where it creates some object
temporarily, and then deletes it some seconds later
Belle. Thavas:
I was going to say, I can see how that would come in handy with rpgbots
Magine: i put
ENQUEUE { (create the object); QWAIT 5000; (delete
it) }
Belle. Thavas:
wow, that is VERY nice!
Magine: yep
Belle. Thavas:
I should try that just to make objects appear and disappear to mess
with people's minds hehe
Magine: more
recently i added a THREAD { } command, similar to ENQUEUE, but
i'll save that for another class session....
Belle. Thavas:
ok great
Belle. Thavas:
well, I think I got quite a bit today
Magine: one
last thing i will mention here, (which i may have mentioned before, but
now it's in context)
Magine: you can
use the menu Options/Handlers... to turn off particular event handlers
entirely
Magine: but i
guess you're right, class has gone overtime, so i'll save further
discussion til next time :)
Belle. Thavas:
I don't have a check next to Handlers
Belle. Thavas:
but if I did..
Magine: you
click that (Opitons/Handlers) and it pops up a dialog listing all the
handlers
Magine: they
should all be checked by default
Belle. Thavas:
ahhh there they are
Belle. Thavas:
yep all checked
Belle. Thavas:
have to doubleclick to activate it
Magine: to
activate what?
Belle. Thavas:
no, worked on one click that time
Belle. Thavas:
I had trouble getting it open the first time
Magine: yeah,
should be jsut one click to check/uncheck
Belle. Thavas:
and you highlighted callbacks
Magine:
yeah...a callback is something like an event, but it occurs when you
can certain functions, instead of in response to world events
Belle. Thavas:
and the warning you have..
Belle. Thavas:
would that apply even more so to the callback functions or pretty much
equal to all buttons
Magine:
yeah...don't uncheck any unless you know what you're doing, or things
might stop working :)
Belle. Thavas:
hehe
Belle. Thavas:
ok, Magine
Belle. Thavas:
thanks for today
Magine: yw :)
Magine: see ya
next time...hope more people show up......and remember to spring ahead
to DST :)
Belle. Thavas:
Yes, thanks for the reminder, and I do too