The Sinclair QL Forum

Easyptr is, as you've found, quite a learning curve, for several reasons.

The manual is not the best ever - it's more of a reference guide than an introduction. It's lacking in examples. At least Norman's guide brings you into the early steps gently, but it was aimed at earlier Easyptr versions before Marcel worked his magic to modernise the software a bit.

There are some more documents on the Easyptr documents page on my site, discussing the use of colours, wman2 and scaling.

I always found that I had to learn by making Easyptr by just making simple, trivial example routines to learn how to use features I'd never used before. So that the mental effort of writing a large program didn't interfere with learning Easyptr. It was to some degree trial and error. And back then it was before QL Forum, so it wasn't as easy to access the experience of people like Bob Spelten, Per Witte and ToFro to ask them complicated questions about the software. After a while, it suddenly changes from being DifficultPtr (as Norman and I used to call it) to Relatively EasyPtr. Then it takes a while before it eventually becomes EasyPtr.

One of the things about programming using Easyptr in BASIC is that there's often more than one way of doing the same thing. That throws you into self-doubt - "Am I doing this the right way?"

It's one of those software packages for me where it's not "what I do" but rather " how often I do it". So keep on plugging with it Martin, you'll get to the point where it all becomes crystal clear soon.

NormanDunbar wrote:

RalfR wrote:

NormanDunbar wrote:I think Tony Tebby wrote great software, but diabolical manuals!

I am sorry, but QPTR was written by Jonathan Oakley.

Don't be sorry Ralf, today I learned something new!

Of course I'm not sure if he wrote the manual...

I got around to trying Dilwyn's pop up message window suggestion, And had another afternoon of frustration with EasyPtr.

As I keep playing around with the window definitions in EasyMenu. I want to get the width and height of the pop up window at run time, by peeking the window working definition.

So I thought. Use MSETUP to get the working definition loaded, and the size of the pop up window. Then MDRAW the window where I want it.

This kind of worked, But the window was drawn in the wrong place. Looking at the values returned by PVAL to get the size and start of the main window as Dilwyn suggested. Showed the wrong values. The values returned are the size and start of the window item under the pointer (The manual does tell you that, but its a bit vague). In my case the pointer was over an application window. Dilwyn's test worked because the window under the pointer must have been the main (outline) window.

And the fun didn't stop there. Not only was the pop up window not where I wanted it, It wasn't even where it was being told the be drawn by MDRAW. I found that if you use MSETUP, then MDRAW, The x and y position values in MDRAW are ignored. I had to use MCLEAR after getting size of the pop up window, to get things to work.

I've currently got it set up to place the pop up window in the centre of the application window. Which is OK so long as I only trigger the pop up when the pointer is over the application window.

In the first versions of PE, there was no need to put any secondaries inside a primary, though I do not know, how the outline (if it existed like now) was handled. You can read this in the sources. And I think, this is the worst thing of PE. I do not know, why this was changed, perhaps to make things easier but more uncomfortable to the user.

The simplest example is a little program, which use the Menu extensions to load a file. Horrible. You have to create a daughter job with a bigger outline to let the user select.

Martin_Head wrote:This kind of worked, But the window was drawn in the wrong place. Looking at the values returned by PVAL to get the size and start of the main window as Dilwyn suggested. Showed the wrong values. The values returned are the size and start of the window item under the pointer (The manual does tell you that, but its a bit vague). In my case the pointer was over an application window. Dilwyn's test worked because the window under the pointer must have been the main (outline) window.

I think this was why I must have mentioned the use of MWINDOW #channel,0 to ensure that the window covered the full menu underneath, not just the item the window was allocated to at the time (e.g. an application window). I don't know the mechanics, but I remember this being an issue in some of my programs in the past.

The description for PVAL implies this (somewhat laterally, as you noticed):

result%(8) to result%(11) gives the coordinates of the window the pointer is in.

Note: window, not menu
Under the description of th.e MWINDOW command, it says that a parameter value of 0 switches the window for that menu to main window outline. In most cases, the outline will be the menu size.

The other thing that gets me with Easyptr commands sometimes is the channel parameter. You can use a number, but then you are running blind. Some of the extensions return an error code on the channel number parameter and I've lost count of the number of times I've been searching for obscure problems when I could have picked up on them by using an integer variable to hold the channel numbers and testing its value on return:
ch% = 0 MDRAW #ch%,win1_test_men
IF ch% < 0 : REPORT ch% : REM oops

For anyone who's interested. I've finally got my EasyPtr program working.

It may still be a bit rough around the edges. And I'm not happy with OUTLN. If I switch out of the program, alter the screen, then switch back. The screen gets restored.

You need menu_rext, and at least one of the mdi/fdi drivers installed (LRESPR them). Then EXEC the imageman_bas program, with imageman_cde in the same directory.

I have included the two EasyMenu _men files, if anyone wants to play with them.

I did try compiling the program. But it gets upset if the mdi and fdi drivers are not pre installed. The BASIC program checks for their existence and configures itself accordingly.

Hi Martin,

When the programme is compiled, cod the MDI/FDI driver code not be included into the compiled programme?

Derek_Stewart wrote:Hi Martin,

When the programme is compiled, cod the MDI/FDI driver code not be included into the compiled programme?

I think, device driver should always be loaded first.

RalfR wrote:

Derek_Stewart wrote:Hi Martin,

When the programme is compiled, cod the MDI/FDI driver code not be included into the compiled programme?

I think, device driver should always be loaded first.

From job 0

Well, technically, you can install a device driver from any job, as long as its memory is owned by job 0 (and thus not removed when the job that started it, ends.

Technically you can also remove a device driver gracefully from the system as long as you "own" it and it provides a call to do remove itsself, but most drivers don't support this (such a function would really rarely be used). As most device drivers also tend to install S*BASIC extensions (which you cannot gracefully remove), this is a bit of a problem.