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


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


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.


QL-Users Mailing List

Reply via email to