Bug reports (2016 Q1)

[SaFeTyPe]

### please see my post from march 18 for the actual bug ###

Hello,
the following has happened to me 6 times now.
OS: Win 8.1 Pro 64
AkelPad 4.9.7 x86

(I currently cannot say if there is a certain trigger/a way to reproduce. But I can say that what I was doing was simply moving very small portions of text within a document (by dragging, and by cut/paste), and occasionally typing a bit. I was doing it quite fast, btw.)

Bug: While editing, suddenly the mouse stays a caret (the vertical line normally shown when there is text underneath the mouse) EVEN when the mouse is over the window buttons (close, maximize, minimize). AkelPad does then no longer take any commands, I cannot click into the text etc. I have to force-close AkelPad in Taskmgr.

Used Plugins:
ContextMenu
Hotkeys
SaveFile:AutoSave
Scripts

Running Scripts:
AkelPadTitle.js
NoOverwriteSelection.js

I can send AkelPad Program/ProgramData folders and Registry Export, if needed.

Is this a known bug?

[SaFeTyPe]

I spent 40 minutes chasing the bug. I think I found it:

1. create a text file that has 10 lines of text.
2. doubleclick into the white area BELOW the text.
3. then quickly move the cursor to the close button of the window and click it.
4. in at least 20% of cases, the mouse pointer will now turn into a line and one cannot close the window and AkelPad no longer to responds.

I was able to reproduce 5 additional freezes that way.

EDIT: I was also able to easily reproduce the bug by simply double-clicking into the white area RIGHT of the text (not below) (which causes selection of the text), and then QUICKLY hitting the close (X) button. so you need not click below the text to reproduce the bug.

EDIT 2: And I was able to reproduce it without doubleclicking, just single click. I opened the text file, *quickly* singleclicked into the area to the right of the lines (they were just empty lines, no text in the that area), and then *quickly* moved the cursor to the close button (X) and the bug occured.

[SaFeTyPe]

found the cause of the bug:
NoOverwriteSelection.js causes the problem.

[KDJ]

SaFeTyPe
I tested in AkelPad 4.9.7 x86 on WinXP x86 and Win-7 x64 and not reproduced.
You are using CmdLineBegin parameter to autostart the script?

[SaFeTyPe]

KDJ
- Yes, I use AkelPadManualSettings.js to start it.

- I can very easily reproduce it. It even happens when I close the AkelPadManualSettings.js window by clicking its (X) on the window bar and then quickly also closing AkelPad.

It does never happen when I unload NoOverwriteSelection.js / or when I remove in from AkelPadManualSettings.js .

However, I installed Akelpad x86 on a Sony Vaio with Win 7 Pro 32, and could NOT reproduce it there. I did not yet configure Akelpad with exactly the same settings/plugins/scripts on the Win 7 32 machine yet though.

If anyone can reproduce the bug on Win 8.1, it might be helpful. However since most will migrate to Win 10 in the next months (so will I), it might be worth it to see if it occurs on Win 10, which would be more important.

[SaFeTyPe]

PS: The bug also occurs when I close via the top left window button and then choose "close" from the menu. As I said, I always have to force-terminate Akelpad then.

##EDIT: And it also appears when closing via the File menu.

[SaFeTyPe]

It seems to be related to the speed. When I open Akelpad, click into the white area, move the cursor on top of the (x) close button (but do not yet click), and then wait 4 seconds and then click, then it seems the bug does not occur. However if I hurry, it occurs often.

[KDJ]

SaFeTyPe
Try to use CmdLineEnd parameter instead of CmdLineBegin (move script call from CmdLineBegin to CmdLineEnd).

[SaFeTyPe]

Hello,
unfortunately, this does not help.

Here is the complete line that is entered (in either CmdLineBegin or CmdLineEnd):

/Call("Scripts::Main", 1, "NoOverwriteSelection.js", "-msg=false") /Call("Scripts::Main", 1, "AkelPadTitle.js", '-t1="(%%D) %%f"')

---
Please note that to reproduce the bug, you might have to repeat the movement I described 10-20 times, perhaps it depends on processor speed or s.th. like that.

(FYI, my Laptop configuration is i5-4200U 4GB RAM 256 SSD 1440p (NEC LaVie Z))

[SaFeTyPe]

OS: Win 8.1 Pro 64
AkelPad 4.9.7 x86

Plugins:
ContextMenu
Hotkeys
SaveFile:AutoSave
Scripts

Scripts:
AkelPadTitle.js
NoOverwriteSelection.js

BUG: when closing, no matter if through X button (top right of window), or through File menu, or through task bar menu, AkelPad freezes:
The cursor remains a caret (vertical line) and nothing can be done any more. The cursor remains a caret also when it is above the (X) close button. Akelpad cannot be closed and has to be terminated forcefully in taskmgr.

the bug occurs also when NO changes were made to the text.

Important: When trying to reproduce, sometimes it takes up to ~50 (!) test closing procedures until the bug eventually occurs.

Note: I am running AkelPad in Administrator Mode. Settings are saved to registry. The loaded text test files are normal, short test text files.


============================================
My configuration:

Options: Watch file change, Don't open file twice, SDI
Codepage: Western 1252 UTF 8; buffer 1024
codepage Ansi lain I/win

undo limit 32000 (detail)
--
left click on marging selects line
rich edit sel
mouse drag
NO right click moves caret

hyperlinks show, sinlge clike

silently close unsaved
save in read-only file warning

save position of modeless dialogs

plugins:
files saving:
Yes Autosaving
No Saving without BOM
Escape key NOT enabled

CmdLineEnd
/Call("Scripts::Main", 1, "NoOverwriteSelection.js", "-msg=false") /Call("Scripts::Main", 1, "AkelPadTitle.js", '-t1="(%%D) %%f"')

MouseOptions: 7
Paint: 1280
Richedit: AkelEdit
ShowModify: 9
SingleOpen 1
StatusPos 0
TabOptionsMDI default
WordBreak 367

[SaFeTyPe]

I believe the bug also causes data loss.

I just changed my font size from 10 to 9 (only one AkelPad window and only one text file was opened).

I closed AkelPad and the bug occurred.

When I re-opened AkelPad, the font size was 10.