EasyPtr4

Anything QL Software or Programming Related.
User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: EasyPtr4

Post by dilwyn »

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.


User avatar
RalfR
Aurora
Posts: 870
Joined: Fri Jun 15, 2018 8:58 pm

Re: EasyPtr4

Post by RalfR »

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...


4E75 7000
Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: EasyPtr4

Post by Martin_Head »

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.


User avatar
RalfR
Aurora
Posts: 870
Joined: Fri Jun 15, 2018 8:58 pm

Re: EasyPtr4

Post by RalfR »

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.


4E75 7000
User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: EasyPtr4

Post by dilwyn »

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


Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: EasyPtr4

Post by Martin_Head »

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.
imageMan.png
imageMan.png (7.05 KiB) Viewed 1014 times
Attachments
ImageMan.zip
(31.41 KiB) Downloaded 64 times


Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: EasyPtr4

Post by Derek_Stewart »

Hi Martin,

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


Regards,

Derek
User avatar
RalfR
Aurora
Posts: 870
Joined: Fri Jun 15, 2018 8:58 pm

Re: EasyPtr4

Post by RalfR »

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.


4E75 7000
Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: EasyPtr4

Post by Martin_Head »

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


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: EasyPtr4

Post by tofro »

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.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Post Reply