Page 3 of 13
Posted: Tue Dec 06, 2011 3:38 pm
by Instructor
KDJ wrote:1.
Run AkelPad from command line in a hidden window and script WindowsList.js:
AkelPad.exe /Show(0) /Call("Scripts::Main", 2, "WindowsList.js") /quit
If you now show AkelPad window (button "Hide/Show"):
oSys.Call("user32::ShowWindow", hMainWnd, 5 /*SW_SHOW*/);
this window looks strangely.
Use
instead of
in your script.
KDJ wrote:In version 4.7.1 AkelPad does not save settings:
Editor 1 -> Tab size
Editor 1 -> Spaces
Fixed.
Posted: Thu Dec 08, 2011 5:04 am
by Instructor
KDJ wrote: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.
Posted: Thu Dec 08, 2011 8:50 pm
by KDJ
Instructor wrote:Use
instead of
in your script.
But SW_SHOWNORMAL changes the window size.
Posted: Thu Dec 08, 2011 9:36 pm
by KDJ
Instructor wrote:KDJ wrote: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.
Posted: Sun Dec 11, 2011 10:12 am
by Instructor
Exactly.
KDJ wrote:Instructor wrote:Use
instead of
in your script.
But SW_SHOWNORMAL changes the window size.
Bug in Macros plugin
Posted: Thu Dec 15, 2011 7:23 am
by Surveyor
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.
Posted: Thu Dec 15, 2011 2:53 pm
by Instructor
Surveyor
Taken into account in new plugin version.
Re: Bug in Macros plugin
Posted: Thu Dec 15, 2011 4:28 pm
by foliator
Surveyor wrote:Foliator has been
posting about a problem with the Macros plugin - assigned keys not responding. I think I may have found the problem.
Not the one I reported, because AkelPad is always maximized on my computer, and recording is never in action when I go to use an already assigned macro/hotkey combination.
We need another way to stop recording if this happens! Right now, the only solution appears to be closing AkelPad.
Yes, as there doesn't seem to be any means of assigning a hotkey to toggle the record function on and off. I experimented with
Call("Macro::Record"), but no such luck.
Posted: Sat Jul 28, 2012 10:27 pm
by qoshinator
The LineBoard track changes function doesn't work properly.
Open a file.
Type "a" -> the line turns yellow.
Save -> the line turns green.
Undo -> the line's marking disappears, when it should be yellow.
Posted: Wed Aug 01, 2012 8:56 pm
by KDJ
Find with regular expressions.
AkelHelp-Eng.htm wrote:\r - Matches a carriage return character. Equivalent to '\x0d'.
It doesn't work.
Windows XP bug - workaround available
Posted: Sun Aug 19, 2012 3:18 pm
by Surveyor
Instructor,
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
Posted: Sun Aug 19, 2012 3:32 pm
by Instructor
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?
Yes, it was door for spammers. Not you ofcourse
Posted: Mon Aug 20, 2012 5:44 am
by Surveyor
Instructor,
Instructor wrote:subclass List View control and send InvalidateRect when WM_VSCROLL with SB_PAGEDOWN or SB_PAGEUP comes
Sorry - subclass, etc. is beyond my understanding! Here is the method I used...
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.
- PAGECOUNT = visible lines in ListView control. Obtained by sending control a LVM_GETCOUNTPERPAGE (0x1028) message.
- BTMLINE = TOPLINE + PAGECOUNT + 2 // extra line at top and bottom, just in case
- If BTMLINE > (rowcount - 1) Then BTMLINE = rowcount - 1 // BTMLINE number is 0 based, can't be larger than (itemcount - 1)
// rowcount should be known already, or use LVM_GETITEMCOUNT (0x1004) message
- Repaint visible portion of grid by sending a LVM_REDRAWITEMS (0x1015) message, passing wParam and lParam as TOPLINE and BTMLINE
That is essentially how I implemented a
fix in AutoIt scripting language - it works fine!
- Surveyor
Posted: Tue Aug 21, 2012 2:35 pm
by Instructor
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).
Posted: Wed Aug 22, 2012 4:08 am
by Surveyor
Instructor,
Instructor wrote:window will be refreshed (flashing) even if bug will not happen
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...
- Surveyor