EASYPTR4 "strange" effect

Anything QL Software or Programming Related.
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: EASYPTR4 "strange" effect

Post by pjw »

BSJR wrote:
pjw wrote:
pjw wrote:<>Does anyone know how to get rid of the scroll arrows in Wman?<>
<>
Maybe there is some flag in the MAWSETUP in memory that can be manipulated like I do for the colours but then also the offsets mentioned above should be adjusted.
Thanks, Bob. I keep forgetting about that "Important_txt" document!

However, I cant find a way forward with this, although I think there must be a way.. Once a menu is added to the mix, you cant have bars on their own.

I have a vague recollection that, back when setting bar and arrow colours in EasyPtr worked, setting the bar and/or arrow colour to the background colour made them to not be drawn.

Its not terribly important, it would just have been nice to have had the choice - for aesthetical reasons.


Per
dont be happy. worry
- ?
Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: EASYPTR4 "strange" effect

Post by Derek_Stewart »

BSJR wrote: The MAWBAR command only does the bars, while MAWBARR also does the arrows (see Important_txt).
Hi,

I can not seem to find the file: Important_txt

Can you tell me where to read it please?


Regards,

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

Re: EASYPTR4 "strange" effect

Post by dilwyn »

Derek_Stewart wrote:
BSJR wrote: The MAWBAR command only does the bars, while MAWBARR also does the arrows (see Important_txt).
Hi,

I can not seem to find the file: Important_txt

Can you tell me where to read it please?
It was in less recent issues of Easyptr and has since been put into the manual. I'll try to attach a copy.
EDIT: can't attach a .TXT text file so I'll try to copy and paste it here.
EASYPTR Manual Updates
**********************

APPMAN
======

The QLiberator compiler instruction for EASYAPP
files is:

REMark $$asmb=?,0,60


EASYEXT
=======

EASYEXT is now V3.02
EASYEXT_txt gives a full description

EASYMENU
========

Version 3.07
++++++++++++

Info and Application windows with border can not be set larger
than the main window in the list menu.


EASYMEN/PTRMEN Extensions
=========================
Version 3.50
++++++++++++

New function MCALLT added, which needs two additional parameters for timeout
job events. Otherwise the sysntax is the same as for MCALL

item=MCALLT #ch%,eve%,time% [,...

eve% and time% are obligatory, i.e. they must be present. eve% must be given as
a name, not only as value, as the event which caused the return will be returned
in eve%. eve% can be used to pass both window events and job events to force a
return. The job events are masked into the upper nibble of eve%.

eve% event to return
= winevevents+jobevents*256
time% timeout to return

MCALLT only works with SMSQ/E from V2.84 or WMAN from V1.52.

ATTENTION:

*******************************************************
* *
* !!!!! MCALLT does not make any version tests !!!!! *
* *
*******************************************************

Version 3.07
++++++++++++

MITEM redraws the correct item ( not the next one)

Version 3.06
++++++++++++

Cosmetics

Version 3.05
++++++++++++

Changes made for SMSQ (MCALL works in SBASIC job 0)

Version 3.04
++++++++++++

MWINDOW with a backslash after the channel number, just sets the window, i.e.
the contents is not affected.
If the menu element number is given as 0, the window is set to the main menu
window size within the main window border.

e.g. MWINDOW #3\1

sets the window to application sub-window no. 1, the window contents and all
window attributes (contents, colour, ink, over status, etc.) are unchanged.

e.g. MWINDOW #3\0

sets the main window area


WSARS now accepts the backslash separator to preserve the save area at the
right place behind the address parameter as described in the manual.
(the previous version expected the backslash before the address parameter)

*****************************************************************************

From Version 2.06 two new commands are available:


MOBJA
+++++

adr=MOBJA ([#ch%][{,}{\}]{num}{info%,inob%})

Parameters as for MTEXT$

separator , object address is returned
\ item address is returned

This function gives the real address of the object
of a loose menu item or an info object element.

By this, an object set for an item can be used by the
programm and must not be present twice.

For specialists:
++++++++++++++++

With a \ separator, the element address is returned.
If the structure (QPTR technical desription) of the
element is known, direct changes are possible.
This should be used with great care, if at all!

Remark: With MWDEF the address of the menu working
definition can be obtained. Thus it it possible to
get direct access to the complete menu definition.
This should be used with great care, if at all!


MAWBAR
xxxxxx

The implementation of new command MAWBARR (see below)
caused a change to the syntax.

The special item number returned by MCALL on an action
on the bars has been changed.
The upper word of the MCALL function value (the lower
word is the application sub-window number as before)
now gives an operation code and the pixel position of
the HIT masked as follows:

bits 0 - 3 operation
bits 4 - 15 pixel position

bits 0 - 3 set mean:

bit 0 section 1
bit 1 join
bit 2 PAN
bit 3 DO

The evaluation can be made with MAWNUM, e.g.


action=MCALL (#ch%)
winum=action
mpnum=MAWNUM(#ch%,winum,x_st%,y_st%)

Then, if winum matches the application window number
where the bars where installed with MAWBAR, mpnum is
the operation code, x_st% gives the pixel position of
the HIT on the bar while y_st% holds the length of the
bar.
If mpnum==0, x_st%==0 and y_st%==0, i.e. the special
item number is 0, then the window itself has been hit.

IF x_st% and y_st% are not present in the MAWNUM call,

mpnum=MAWNUM(#ch%,winum)

then mpnum is the full item number with the operation
code and the pixel position masked as described above.

Where op_code=mpnum && 15
and pix_pos=INT(mpnum/16)

will give the values.

The operation code in bits 0 - 3 gives the following
meanings:

op_code=0 HIT on SCROLL bar in section 0
1 HIT on SCROLL bar in section 1
(if split)
8 DO on SCROLL bar, split
10 DO on SCROLL bar in section 0, join
11 DO on SCROLL bar in section 1, join


op_code=4 HIT on PAN bar in section 0
5 HIT on PAN bar in section 1
(if split)
12 DO on PAN bar, split
14 DO on PAN bar in section 0, join
15 DO on PAN bar in section 1, join


MAWBARR
+++++++

As MAWBAR and additionally the arrows are drawn.
The syntax is the same as for MAWBAR, but no split is
possible.

The special item number returned by MCALL is as
described above, if an action occured on the bars.
If the arrows have been hit, then the pixel position
masked in bits 4 - 15 is set to -1 (all bits set),
and the operation code masked in bits 0 - 3 is as
follows:

bit 0 always 0
bit 1 scroll down or pan right
bit 2 pan
bit 3 DO

This gives the following meanings:

op_code=0 HIT up
2 HIT down
4 HIT left
6 HIT right

8 DO up
10 DO down
12 DO left
14 DO right


If MCALL returned from an action in an application
sub-window where bars and arrows are set up with
MAWBARR, the an immediately following MWINDOW called
with the MCALL function value, will set the window
size to the area within the arrows.

END
***


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: EASYPTR4 "strange" effect

Post by mk79 »

It's all been too long ago and the code is very very tough to read. But I don't think there is any provision in EasyPtr for you to get the standard menu handling without the arrows. You could try patching wwa_xoff/wwa_yoff to 0 in the working definition, it's used at some point to decide on whether to draw the arrows or now. No idea what other implications it might have...


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

Re: EASYPTR4 "strange" effect

Post by Derek_Stewart »

Hi,
Thanks to Dilwyn, I can see where the "important_txt comes in, I am a little worried, that there is varying versions of the document around.

I like to read the current version of the Easy Pointer manual, not earlier versions with update files.


Regards,

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

Re: EASYPTR4 "strange" effect

Post by Derek_Stewart »

mk79 wrote:It's all been too long ago and the code is very very tough to read. But I don't think there is any provision in EasyPtr for you to get the standard menu handling without the arrows. You could try patching wwa_xoff/wwa_yoff to 0 in the working definition, it's used at some point to decide on whether to draw the arrows or now. No idea what other implications it might have...
Hi,

Why not put the EasyPointer source code on Git Hub, so that more than obe person can update the source code.


Regards,

Derek
User avatar
BSJR
Trump Card
Posts: 182
Joined: Sun Oct 18, 2015 12:53 pm
Location: Amsterdam
Contact:

Re: EASYPTR4 "strange" effect

Post by BSJR »

Derek_Stewart wrote:
BSJR wrote: The MAWBAR command only does the bars, while MAWBARR also does the arrows (see Important_txt).
Hi,

I can not seem to find the file: Important_txt

Can you tell me where to read it please?
I see Dilwyn already found it.
The txt I referred to was from EP3 and printed & added to my EP4 manual pdf, it was not part of this pdf from 2005.
I found a later version which included some version info, as in Dilwyn's text, and turned that into a pdf.
EP4_important.pdf
(20.72 KiB) Downloaded 63 times


User avatar
BSJR
Trump Card
Posts: 182
Joined: Sun Oct 18, 2015 12:53 pm
Location: Amsterdam
Contact:

Re: EASYPTR4 "strange" effect

Post by BSJR »

mk79 wrote:It's all been too long ago and the code is very very tough to read. But I don't think there is any provision in EasyPtr for you to get the standard menu handling without the arrows. You could try patching wwa_xoff/wwa_yoff to 0 in the working definition, it's used at some point to decide on whether to draw the arrows or now. No idea what other implications it might have...
I did a quick test with an SBasic version of SuQcess2. Setting the above mentioned wwa_x/yoff to zero after a MAWSETUP.
And indeed the arrows are not drawn and even after splitting the main AW into 4 sections none of them shows any arrows.
Bars are drawn both horizontal and vertical as expected.
Below I added the Proc I use to fix some values in the AW Working Definition.

Code: Select all

 DEFine PROCedure ARROW_BAR (chn%)
 REM >>>200 N: set menu arrow/bar colours
 REM >>>203 +: colour globals moved to Init
 LOCal apw%,ii%,wrkd,wndd,alst,appw,arrc%,barc%,bsec%,awbg%
  arrc%= h223%: barc%= h221%: bsec%= h222%
  wrkd= MWDEF(#chn%)
  apw%= PEEK_W(wrkd +110)         : REM >>> $6E how many appwndos?
  REM:: apw%=0                   : REM >>>T test: loop off
  IF apw%
   alst= PEEK_L(wrkd +112)        : REM >>> $70 find app-work list
   FOR ii% =0 TO apw% -1
    appw= PEEK_L(alst +ii% *4)    : REM >>> find each appwork defn
    SELect ON ii%
     =0 : apxs%= PEEK_W(appw): apys%= PEEK_W(appw +2) : REM >>> for testinfo
      awbg%= h21B%                : REM >>>203; set paper colour =available
     =1 : IF chn% =kmain% : awbg%= h236% : REM >>>203; set paper colour =available (index)
    END SELect
    REM : POKE_W appw +14,awbg%        : REM >>> $0E, set paper colour =available
    POKE_W appw +12, h216%       : REM >>> $0C,$216 set border colour
    REM >>> 252 =m/c/chk. $216 wordt door MAWDRAW als QL kleur gezien, gel/grn/chk
    POKE_W appw +64, arrc%       : REM >>> $40, set pan arrow colour
    POKE_W appw +66, barc%       : REM >>> $42, set pan bar colour
    POKE_W appw +68, bsec%       : REM >>> $44, set pan section colour
    POKE_W appw +94, arrc%       : REM >>> $5E, set scroll arrow colour ($40+$1E)
    POKE_W appw +96, barc%       : REM >>> $60, set scroll bar colour
    POKE_W appw +98, bsec%       : REM >>> $62, set scroll section colour
    :: POKE_W appw +148, 0  : REM >>> $94, set aw.offset
    :: POKE_W appw +150, 0  : REM >>> $96, set aw.offset
    REM : POKE_W appw +108, awbg%      : REM >>> $68 +$04,set avail colour
   END FOR ii%
  END IF
 END DEFine ARROW_BAR
 ::



User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: EASYPTR4 "strange" effect

Post by pjw »

Thanks, Marcel! Your suggested hack certainly switched off the arrows.
I havent got round to any real life testing yet, but I did find that I
had to turn off splits too, as split menus then no longer work:

Code: Select all

if peek_w(appw + wwa_nysc) then:	rem There is a scroll section
  SetAttr appw + wwa_clen%:		rem Set bar attributes
  poke_w appw + wwa_yoff, 0:		rem Switch off menu section
  poke_w appw + wwa_nysc, 0:		rem Disallow splits
 endif
(I'll dump the polished routine here, if it all goes according to
plan..)
Note: I only intended this for simple, two-dimensional drop-down
menus, so if that works, my work here is done - on this occasion.


Per
dont be happy. worry
- ?
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: EASYPTR4 "strange" effect

Post by pjw »

Although the arrows can be switched off Wman still makes space for
them and there is no easy way to counter that. So it ends up looking
even weirder than a menu with the arrows in place.

Im sure there are ways and means.. but for now Im giving up on this.

Thanks for all tips and help with this!


Per
dont be happy. worry
- ?
Post Reply