2.
If in edit window is opened NTFS stream, then does not work commands "Open" and "Save As".

Dialogs now open, but GetOpenFileName/GetSaveFileName don't work with streams.

If you open a stream, eg "C:\abc.txt:NamedStream", you can pass to GetSaveFileName function
as lpstrFileTitle (component of OPENFILENAME structure) the file name:
"abc.txt_NamedStream".
This allowed to save the stream into a file with this name.

Foliator has been posting about a problem with the Macros plugin - assigned keys not responding. I think I may have found the problem.

If you Call the Macros plugin, then start a Record session, normally there is a tiny window at the top-right corner of AkelPad, used to stop recording. However, if AkelPad is NOT maximized, and the top-right corner is off screen (i.e. window is shifted to the right a bit), then the "stop recording" window in not visible and CANNOT be accessed. I can find no way to stop recording (stop 'window' is not listed in task manager), or to "stop" the Macros plugin. When this happens, any hotkeys assigned to macros are non-functional, as a recording session is still open.

We need another way to stop recording if this happens! Right now, the only solution appears to be closing AkelPad.

Windows XP (still much in use, and popular!) has a long-standing bug in how it handles gridlines in the ListView control. This affects, for example:

the Plugins dialog in AkelPad

the Macros plugin dialog

others - Hotkeys?, etc. that use the ListView control with gridlines

I understand (?) the bug has been fixed in Vista and Windows 7, etc. Behaviour is that when scrolling, the repainting of the lines is 1 pixel out, so they either disappear or get scrambled, depending on the window size.

I had previously (2009) posted a comment about this bug here, but did not know at the time that it could be fixed relatively easily.

I have devised a fix which I implemented in a little AutoIt (scripting language) program. Another programmer also implemented my fix in a C++ file manager program - it works!

Let me know if you think it is worth implementing - I will PM you with the procedure (not difficult - I am not a good programmer, but even I understand how it works).

Quick question re: the forum - I have a signature in my profile which used to be inserted in posts, now it is NOT. Is this behaviour changed?

Surveyor
I also use only XP, other just for testing. As you know - this is standard control bug. I suppose there need to subclass List View control and send InvalidateRect when WM_VSCROLL with SB_PAGEDOWN or SB_PAGEUP comes. But it does not bother me and I don't want to subclass window only for this.

Surveyor wrote:

Quick question re: the forum - I have a signature in my profile which used to be inserted in posts, now it is NOT. Is this behaviour changed?

Detection
Program's message loop waits for a WM_NOTIFY (0x004E) message; lParam points to a NMHDR structure which contains the secondary message. When the secondary message is LVN_ENDSCROLL (-181), then scrolling operation on a ListView control just ended - action needed.

Action
Repaint grid (always!), in the following manner:

TOPLINE = first visible line. Obtained by sending control a LVM_GETTOPINDEX (0x1027) message.

TOPLINE -= 1. // a partial line could be showing - use line above
If TOPLINE <0 then TOPLINE = 0.

Surveyor
LVN_ENDSCROLL doesn't contain information about how window was scrolled. This means that window will be refreshed (flashing) even if bug will not happen (bug appear only when mouse pressed arrows or paging window with mouse).

Yes, that's right, but in my application (scripted, slow execution), there is no flashing and repaint takes almost no time, I think. User is not using the Plugins dialog continuously while AkelPad is open, so repaint does not use up a lot of processing time. A more elegant fix would only repaint when grid is scrambled, but how can you detect that? - scrambling is dependent on window size, I think. Too much work to figure out when scrambling actually occurs. I would love to see a real fix (patch) in one of Windows' DLLs - I think that the problem is that scrolling is 1 pixel out, so a real fix would only change a single byte! It's a shame Microsoft never fixed it in one of the Service Packs. But, I have never seen a patch on the Internet...