The Sinclair QL Forum

HAOUI wrote:Factually the overhead is exactly 236 bytes for wman

OK, that's actually less than I had remembered, certainly not a problem for SMSQ/E, sorry! My main issue here was telling that it's available and asking if somebody maybe has a usage for it in mind.

I just have to occasionally test things on a 640KB QL and wow that memory fills up quite fast! Unfortunately to some degree that's also my fault, so I started checking where to reduce code size about a year ago...

Cheers, Marcel

dilwyn wrote:I guess it's a documented feature (QPTR guide etc), so purely in that respect it should be included. But I do take the point that it's rarely if ever been used.

Alain, do you have a specific need for it in software, or is it just that you have spotted the problem and wish to get it fixed?

As far as I can remember, the implementation is fully conform/compliant to the documented feature for API, data structures, associated sources and styles guides.
Perhaps, should be suppressed in documentation all mentions saying feature not implemented/not working/should not be used.
One mention to be added describing the flag activation for programs wishing to use the feature, otherwise everything goes as before and no incidence for existing programs.
Finally it's up to MK & WL to confirm and evaluate the opportunity when/if time/space permits.

HAOUI wrote:

dilwyn wrote:I guess it's a documented feature (QPTR guide etc), so purely in that respect it should be included. But I do take the point that it's rarely if ever been used.

Alain, do you have a specific need for it in software, or is it just that you have spotted the problem and wish to get it fixed?

As far as I can remember, the implementation is fully conform/compliant to the documented feature for API, data structures, associated sources and styles guides.
Perhaps, should be suppressed in documentation all mentions saying feature not implemented/not working/should not be used.
One mention to be added describing the flag activation for programs wishing to use the feature, otherwise everything goes as before and no incidence for existing programs.
Finally it's up to MK & WL to confirm and evaluate the opportunity when/if time/space permits.

I wonder how QSpread fixed this problem when implementing the index items.
For a QPTR version of SuQcess I also tried to use the index item, only to find out later it didn't work at all.
In the end I stuck to the old way of using extra AWs, that need to be moved in sync with the main AW by the program.
Of course QSpread was all assembler while the current SuQcess is done in SBasic with EasyPTR with only a horizontal index.

BSJR

BSJR wrote: I wonder how QSpread fixed this problem when implementing the index items.
For a QPTR version of SuQcess I also tried to use the index item, only to find out later it didn't work at all.
In the end I stuck to the old way of using extra AWs, that need to be moved in sync with the main AW by the program.
Of course QSpread was all assembler while the current SuQcess is done in SBasic with EasyPTR with only a horizontal index.

Well, while doing I had a quick look over some QL spreadsheet and similar softwares using indexes and scrolled menus.
Indeed, QSpread handles indexes with its own (long) assembler code and the result is really very good.
The others used various tedious and painfully non standard/unified methods.
EasyPtr doesn't support indexes and I don't see how it can do it without a new Wman.
QPTR supports fully indexes but it is the Wman responsability to do Drawing, Update, Scrolling and Spliting operations.
Unfortunately, QPTR had some bugs in this area and packed wrongly datas but this had no importance as Wman doesn't use them at all.
What I did is exactly what was planed from the begining.
Using the fixed QPTR and the implemented Wman allows a full standard support of indexes as expected without any extra code.
I am really wondering how this cavity had never been treated over years and years, while several concerned softwares had been developed.
Damage, seemly it's too late but it is a pleasure to get it done anyway despite the wasted effort. Alain

Alain, I think there was so much about software like Easyptr and QPTR that was poorly explained and lack of working examples - I think a lot of people tried, failed to get it to work, and assumed they were doing something wrong, gave up and implemented their own way of doing things.

What Dilwyn said!

I tried the raw QPTR interface, got lost in poor documentation for a beginner. I used to wonder how Jochen was able to create decent applications with such poor docs. I gave up.

Then came EasyPTR 2. "Great!" I thought, and bought a copy from Dilwyn. (I think.) Given the state of the QPTR docs, I figured easyPTR would be better. Wrong! Dilwyn and I used to talk about this application and named it difficultPTR for ages. Again, I gave up.

(But I'm no quitter!)

One day, or one whole weekend rather, I sat down with difficultPTR going through what information there was in the manual and looking at the examples and tring stuff out. I eventually figured out how things actually should be done and wrote my notes up in the "Pointer Environment, Idiots Guide" aka PEIG.

I also did a couple of tutorials for Quanta magazine.

My next step to stardom was finding out how the hell to get QLiberator compiled programs to actually work with EasyPTR applications. It eventually proved to be simple, just add '\0' to the end of any eastPTR commands. I have no idea why!

I think it was these, and other, problems with various softwares that gave me the impetus to start writing stuff in language that otherss couuld hopefully follow, leaading to a long and distinguished career as an author in IQLR and QL Today, before taking my skills to the Firebird Database project, and work where I was often commended on the quality of my docs. (Bur strangley, never on my spelling!)

From there, a book publishing contract was obtained and here I am.

Cheers,
Norm.

Well, it was your PE Idiot's Guide and the tutorial on Easyptr which got me going and I never looked back.

The bit about adding \0 at the end of the command is actually a QLiberator-ism rather than Easyptr. The Easyptr manual actually warns of this, that if a parameter list needs to end with a backslash (and some Easyptr extensions do use a backslash e.g. MINPUT #channel%,text$\ you need to add a dummy parameter to get around the issue with QLiberator. So that example command becomes MINPUT #channel,text$\\0 for example (the dummy extra parameter works around QLib's limitations.

dilwyn wrote:I guess it's a documented feature (QPTR guide etc), so purely in that respect it should be included. But I do take the point that it's rarely if ever been used.

I use it in my email client, and so does QPOP3.

Peter wrote:I use it in my email client, and so does QPOP3.

You use a feature that doesn't yet exist?

By the way, I'll have a closer look at the code when time permits. I think I've come to the conclusion that it should be included, just 200 something additional bytes is pretty good. A problem might be support from the PE libraries. QPtr is fixed I hear, but if it isn't already supported/prepared to be supported by EasyMenu/EasyPtr in some way I don't think I have the mental strength to add it