Op Tue, 28 Aug 2018 15:26:22 +0200 schreef Marcel Kilgus via
Ql-Users <ql-users@lists.q-v-d.com>:
Bob Spelten via Ql-Users wrote:
Per already mentions the jumpy resize behaviour.
I frankly don't quite see what's jumpy about it?
My default QD size is 80 columns by 40 lines, and I like that a size
DO makes it maximize the height.
But setting a custom width, moving the "size" to the left, is where
the right side also moves left. Jochen once explained that size
grows in discrete steps but I would expect the right side to be
anchored, now full screen can never be reached.
It seems that the bigger the move to the left, the more the right
moved along with it.
Uh-oh. I think we have conflicting wishes here. If I understand you
correctly, you are not able to re-size the the WIDTH of the window by
HITting the window resize button and moving the icon to the left.
Right? To achieve that you needed to DO the window resize button,
which makes the window expand to maximum, something that no longer
works in VB0.xx.
The thing is, you CAN resize the window width using the standard Wman
resize mechanism, but you need to move the resize icon some 150 pixels
or more to the left for the next allowable width increment. I guess
you need a screen width of at least 640 pixels, and to move the QD
window as far right as possible to be able to resize the width to the
next level. Thats why you wish for the old VA.xx behaviour.
I agree this stepwise increment is a nuisance. Ideally the increment
should be in the order of one or a few character widths; not 20.
In VB.01 the behaviour changed somewhat. DOing the resize button would
only maximise the HIGHT, leaving the width at whatever one had
labouriously managed to set it (I usually prefer 100 columns for
working). So that wouldnt help you, Bob. In VB0.3 the behaviour
changed again. Now DOing the resize button annoyingly resets the width
to 80 coloumns for some reason as well as maxing the hight.
There are a number of bugs in QD. I shant list them here, as that
might be seen like "looking a gift horse in the mouth", or worse:
nagging ;)
There is one serious bug though, that I hope will one day be tackled
by some brave and patient soul. Its hard to demonstrate and almost
impossible to catch in the act. In fact some people, including Jochen,
deny its very existence: Its the "Creeping last line/rubbish bug". A
scan through the SMSQ/E sources should convince doubters of its
existence. In a number of files youll see a many lines gap from the
last code line to the END directive. Heres one:
dev8_iod_con2_qpc8_mblock_asm, from 2003 with a 37 line gap!
That implies that you wont always see the problem, because its
off-page. Whats worse is that you dont always know what the last line
contains. Here are some with some rubbish at the end
dev8_dv3_q68_sdhc_wsect_asm
dev8_dv3_q68_win_card_xxxx_asm
both from 2018. Since the rubbish is past the END it wont matter here,
but you can see the potential for strange, inexplicable bugs in other
code - or perhaps even a nasty letter where you thought youd deleted
what you really thought of someone..
The oldest Ive found in the SMSQ/E source files, so far is
dev8_iod_con2_16_recol_asm
from Dec 1998, ie just after QD VA.06 came out. Perhaps there is a
connection?
I did a general tidying up of the source files a year or two ago, so I
caught a lot of the most extreme cases and fixed them, but I left a
few for posterity - and new ones have emerged since.
Anyway, that was just to try to convince any unbelievers. The issue
has been with us for a very long time. I believe it has something to
do with QD's block handling: copy, replace, delete..? But, as I said,
its hard to get a clear idea of when it happens. Not least because
most(?) of the time it happens out of sight below the bottom of the
visible text.
Per
_______________________________________________
QL-Users Mailing List
