The Sinclair QL Forum

They look beautifull

I hope you dont mind my suggestions..

Use RDPT instead of INKEY$ in the waiting loop. Looks better and works
better. You could then also use your own pointer icon..

There is some flickering: Avoid screen refreshes when no info has changed

There should be a utility to put on a Hotkey to pick all WiQget programs
to the top of the pile, as for buttons. For example you could scan the
jobtree for any jobs that start with "QTW " and Pick them, eg:
RAM is a perhaps not a good choice for using as the default device, as
accessing each ram disk causes it to be initialised, using up a lot of
memory. I researched this once, but cant remember the result, only that it
was a bad idea Better, perhaps to use WIN as the default as most SMSQ/E
systems will have at least one, or failing that use FLP. Heres a tip on
scanning for which devices are available. RUN in a normal SBASIC:
Funny you should be doing this right now. Its very similar to what I was
doing, when I briefly stoppped to download and test your offerings. I have
a few little programs that I use for user input/output, similar to JMS'es
QMenu: Get a filename, date, colour, etc, or display a help screen, popup
text etc. They are mini menu programs, that all have a few characteristics
in common, which the calling program controls by passing parameters on the
command line, and reading the return values. There must be something in
the wind..

BTW, you are assuming everyone using your program has ptrmen loaded at
boot time?

Keep QLing!

Per

pjw wrote:They look beautifull
I hope you dont mind my suggestions..

They make me very happy!
I need feedback to improve my work.

Use RDPT instead of INKEY$ in the waiting loop. Looks better and works
better. You could then also use your own pointer icon..

Ok, I'll try ASAP

There is some flickering: Avoid screen refreshes when no info has changed

That sounds strange, on two computers, where I tested the programs have not noticed flickering and sightseeing program (which is very simple) makes the refresh only the data changes.
Can you tell me in which programs in particular have noticed the flicker?

There should be a utility to put on a Hotkey to pick all WiQget programs
to the top of the pile, as for buttons. For example you could scan the
jobtree for any jobs that start with "QTW " and Pick them,

Now that's a good idea!

RAM is a perhaps not a good choice for using as the default device, as
accessing each ram disk causes it to be initialised, using up a lot of
memory. I researched this once, but cant remember the result, only that it
was a bad idea Better, perhaps to use WIN as the default as most SMSQ/E
systems will have at least one, or failing that use FLP.

You're right, but the choice of default has been made to have the simplest and smallest possible code.
I think eventually occupy more time and resources to scan the available devices, physical access to data is much slower.
I not, however, exclude the possibility of changing that in the next version.

Funny you should be doing this right now. Its very similar to what I was
doing, when I briefly stoppped to download and test your offerings. I have
a few little programs that I use for user input/output, similar to JMS'es
QMenu: Get a filename, date, colour, etc, or display a help screen, popup
text etc. They are mini menu programs, that all have a few characteristics
in common, which the calling program controls by passing parameters on the
command line, and reading the return values. There must be something in
the wind..

Very interesting, why not join forces in a common project?

BTW, you are assuming everyone using your program has ptrmen loaded at
boot time?

Exactly, I forgot to write it in the documentation

This however is a first primitive version, almost a beta.
Thanks to the valuable tips you have given me today and to those who gave me Urs Koenig time ago I'm going to completely rewrite the code and possibly create new WiQget.

Giorgio Garabello wrote:

pjw wrote: There is some flickering: Avoid screen refreshes when no info has changed

That sounds strange, on two computers, where I tested the programs have not noticed flickering and sightseeing program (which is very simple) makes the refresh only the data changes.
Can you tell me in which programs in particular have noticed the flicker?

I havent caught it in the act yet, but I do notice a distracting flicker in the Lower RH corner of my screen This is always an issue with EasyPtr. Many times I have to have different levels of refresh: Too much and there is flicker, too little and the screen gets messed up. Right now Im trying to sort out an intractable problem of this kind in one of my own programs, so thats what I feel I should be concentrating on

Funny you should be doing this right now. Its very similar to what I was
doing, when I briefly stoppped to download and test your offerings. I have
a few little programs that I use for user input/output, similar to JMS'es
QMenu: Get a filename, date, colour, etc, or display a help screen, popup
text etc. They are mini menu programs, that all have a few characteristics
in common, which the calling program controls by passing parameters on the
command line, and reading the return values. There must be something in
the wind..

Very interesting, why not join forces in a common project?

When a critical mass of my tools are sort of ready, Ill try to put them up on GitHub. You could do the same with yours..

BTW, you are assuming everyone using your program has ptrmen loaded at boot time?

Exactly, I forgot to write it in the documentation

Since EasyPtr is one of the easiest ways to produce menu-type programs (Yes, I have considered other methods) and since it is now free, couldnt we be allowed to assume that everyone wishing to use such programs will have ptrmen_cde loaded at boot time, to avoid having to add the 8-15Kb toolkit to every tiny applet? IMHO, ptrmen_cde should be considered a strategic core extension on high-end PE systems, together with the likes of QLib_run, FI2, etc..

Per

Per