|
 - Forum
 - iziBasic
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 257
 Sujet n° 1528 |
Flushevents |
le 12/04/2007 @ 19:30
par JoeV
|
Hello Everyone,
I must not understand flushevents. Can someone please enlighten me?
My app detects hard keys that can be held down for extended periods of time. When the program exits, it will occasionally jump either to the Appointment Book or to Contacts, these correspond to hard keys -21 & -22 on my palm. The following simple prog illustrates what I am seeing:
{MINOSVERSION "5.0"}
{KEYEVENTS ON}
BEGIN
repeat
a=doevents
print a using 0 'so I can see the events
for i=1 to 1000 'waste some time
b=pi*pi
next
‘flushevents ‘flushevents here, no cure
until a=-11
‘flushevents ‘flushevents here, no cure either
END
If you run the above prog and hold down hard key -21 or -22 for several seconds, then exit with a page up key, it exits incorrectly, that is, directly to the app corresponding to -21 or -22. This seems like a perfect use for flushevents. Therefore, I have tried flushevents in both of the locations shown above. However, no fix. Shouldn't flushevents clear the event queue and exit my program correctly?
Thanks,
JoeV
|
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Réponse n° 1
--------
le 13/04/2007 @ 00:03
par aldweb
visiteur
|
Hello JoeV,
FLUSHEVENTS is a bad name, I should have chosen another one... like: PROCESSEVENTS.
Indeed, this statement does not clear the event queue, it processes pending system events.
The iziBasic runtime runs the events loop every single statement. If the events arrive faster than the statements are processed, then the queue can get overloaded. FLUSHEVENTS just makes sure to process these events before moving to the next statement.
You will need to write a quick PP applet (and I know you are very good at that  ) to really flush the events queue (at the place of your 2nd invoking of this statement).
The 1st invoking of your FLUSHEVENTS would make sense for slowlier devices than yours (one running on an old DragonBall processor, not your great ARM device ).
Cheers,
aldweb
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Réponse n° 2
--------
le 20/04/2007 @ 19:29
par Supertrucker
visiteur
|
JoeV,
Please let me know when or if you write this PP applet. I bought a couple of books on Turbo Pascal, so I plan on getting my fingers dirty, but as of now, I don't understand PP at all!!
I'd appreciate any help!
Thanks,
Andrew aka Supertrucker |
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Réponse n° 3
--------
le 21/04/2007 @ 02:02
par JoeV
visiteur
|
Hello Andrew,
I have already written the applet but it is extremely trivial. It is posted below. For something with more "meat", check out my applet called "a faster doevents" posted under samples in the wiki. I am, by no means, a pascal wizard. I know just enough to be dangerous. There are more applets that may be downloaded on the iziBasic home page. You'll need the pp compiler, so when you download it, it will have many more applets to study. Hope this helps.
Regards,
JoeV
p.s. Aldweb, perhaps your next version of iziBasic might have a statement called "FLUSHQUEUE"? 
{ 13-Apr-2007
This applet flushes the event queue.
Call the applet from izibasic using the format: R$=CALLPP(161)
R$ always returns "Events Cleared"
}
{$code appl,JVxx,code,161} //required by iziBasic
program ppcall161;
{$i PalmAPI.pas}
type
iBasFunType=function(S:string):string; //required by iziBasic
var iBasCallPP:iBasFunType; //required by iziBasic
function EvtFlushKeyQueue:Err;inline(SYSTRAP,$A12C);
function EvtFlushPenQueue:Err;inline(SYSTRAP,$A125);
function EvtFlushNextPenStroke:Err;inline(SYSTRAP,$A129);
function CallPP(S:string):string;
begin
EvtFlushKeyQueue;
EvtFlushPenQueue;
EvtFlushNextPenStroke;
callpp:='Events Cleared'; //return string
end;
//Main. Required by iziBasic
begin
iBasCallPP:=CallPP;
end.
|
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Réponse n° 4
--------
le 21/04/2007 @ 17:51
par aldweb
visiteur
|
p.s. Aldweb, perhaps your next version of iziBasic might have a statement called "FLUSHQUEUE"?
That could be useful indeed. But it is also true that I did not work too much on the last version of classic iziBasic since one year. I am currently investigating a 100% ARM port of iziBasic. Soon, you should see a tinyBasic interpreter here, as a first work and proof of concept of the future iziBasic...
Cheers,
aldweb
|
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Réponse n° 5
--------
le 22/04/2007 @ 14:23
par JoeV
visiteur
|
Aldweb,
That is great news! I look forward to it and would like to do some speed comparisons. ARM is indeed the direction to go. If all goes well, do you plan a full version (like iziBasic) ?
Regards,
JoeV
|
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Réponse n° 6
--------
le 22/04/2007 @ 23:49
par aldweb
visiteur
|
Don't be too enthusiastic dear JoeV.
I have been thinking a lot about how to develop the future iziBasic ARM.
More or less, I planned to study see 3 ways:
#1. a simple Basic interpreter as an extension of a tinyBasic (the one I initially developed in iziBasic, currently being ported to NaPP)
#2. a tokenized Basic interpreter, which should be average in terms of performance, but much easier to develop and maintain than the current iziBasic
#3. the port of the current iziBasic source code, which should be the optimal way of proceeding as performance is concerned
Because applications compiled for ARM are much faster than the same applications compiled for 68k, I would have expected good execution speed for my tinyBasic ARM interpreter, even if not optimized at all in terms of performance. The surprise came tonight when running my Bench2 analysis: this tinyBasic ARM interpreter is too slow.
So, option #1 is out.
I shall move to option #2 then.
Why didn't I consider option #3 directly you might ask? Just for two reasons:
- iziBasic is a hobby for me, so I'd rather have fun coding something new than basically porting the current source code
- I want to train myself well on NaPP before moving to some important project and these tiny Basic and tokenized Basic seemed to be a good and fun way to reach this objective
Cheers,
aldweb
|
|
|
|
sujet actif
 sujet clos
 Important!
 Nouveau message -
 Rectifier message
 Clôturer sujet
 Remonter
|
|
I. aldweb
![[de]](img/de.gif)
![[es]](img/es.gif)
![[it]](img/it.gif)
![[pt]](img/pt.gif)
Haut 
© 2004-2013 
