122 replies to this topic

[Ronins]

GREAT wrapper... Simply amazing...

However, i ran into several questions.. Can you please clear them up for me?

----------------------------------------------------------------

I tried this::

sci.GetLine(0, myvar)
ToolTip % myvar

but when typing really quick, it produces the wrong result.

Even after typing really fast, and then changing lines, and then waiting, the real text required is often followed by some random text/number either on same line, or on next line..

So, am i doing that wrong, or is it some bug?

I use 32 bit unicode AHK on 32 bit win7

 

----------------------------------------------------------------------

 

Also, I corrected this one..

according to documentation, this should be valid

sci.GETCURLINE(<size>, myvar)

However, this isnt according to your wrapper..

Therefore, at 68, this should be added to make this work::

(msg = "GetCurLine") ? (VarSetCapacity(lParam, this.linelength(wParam)+1 * (a_isunicode ? 2 : 1)), lParam := &lParam, buf:=true) : null

--------------------------------------------------------------------

 

I also tried to change the color of margin for one line only (I mean line number here)

Example here (From sublime text 2)::

 

I used marker (background) to change a single line of editor area, (fullrect to change margin color), but it didnt work..

Any idea about that??

-------------------------------------------------------------------

Regards

[RaptorX]

I had the same issue .. no fix yet..
But here is the deal
 
I created a editor that works flawlessly on my desk top at home and  desktop at work.. but this one issue came up when i went to place it on my HP laptop (with brand new win 7 64bit) 
Im am running AHK_L 32 for compatibility issues .. but this is a head scratcher..
 
each computer is configured the same.  so IDK what to think
 
I also notices a error in the sci.ahk file that shows up only on my office computer.. a simple error dealing with a message that starts with a % but has is only text no equations .. remove the % and it works .. not sure why the difference

Anybody using Autohotkey x64 will have issues with the wrapper because Scintilla is a x32bit only dll.
I always test all my examples before uploading them and they are working. please check that you have the latest version. I tried this example and it works without issues.
 

Sorry for late.
v2 is just a bit different in variable name and assignment.
- change "=" --> ":=" in all of your functions. it's easy and i can do that.
- change all of your variable name beginning with number (%hwnd%) to new names beginning with character, maybe _%hwnd%. i can't do that.
thanks,
CE

I will be taking a look at that even though I am not sure what do you mean by changing = to := in functions... isnt it for the whole file?
chaning the names that begin with numbers should be easy too, i will update it later on.
 

GREAT wrapper... Simply amazing...
However, i ran into several questions.. Can you please clear them up for me?
----------------------------------------------------------------
I tried this::

sci.GetLine(0, myvar)
ToolTip % myvar

but when typing really quick, it produces the wrong result.
Even after typing really fast, and then changing lines, and then waiting, the real text required is often followed by some random text/number either on same line, or on next line..
So, am i doing that wrong, or is it some bug?
I use 32 bit unicode AHK on 32 bit win7
 
----------------------------------------------------------------------
 
Also, I corrected this one..
according to documentation, this should be valid

sci.GETCURLINE(<size>, myvar)

However, this isnt according to your wrapper..
Therefore, at 68, this should be added to make this work::

(msg = "GetCurLine") ? (VarSetCapacity(lParam, this.linelength(wParam)+1 * (a_isunicode ? 2 : 1)), lParam := &lParam, buf:=true) : null

--------------------------------------------------------------------
 
I also tried to change the color of margin for one line only (I mean line number here)
Example here (From sublime text 2)::

 
I used marker (background) to change a single line of editor area, (fullrect to change margin color), but it didnt work..
Any idea about that??
-------------------------------------------------------------------
Regards

For the first issue I have confirmed that it is a bug, even though i do not understand what you mean by "typing fast" because if you are getting the whole line it doesnt matter how fast you type. I did however found that the error shows only in the LAST line of a file, so if your file has 4 lines, lines 1-3 will behave normally but line 4 would append a random number at the end.

I also found that if you put a new line in the last line, that random number will dissapear. I will try to see what causes it.

Thanks for the fix, I do have to add a few manual buffers and I can only add them when I, or sombody else uses the function and tell me that it needs a buffer because i havent read the whole scintilla documentation... yet... hehehe, so thanks again!

for the last point I will have to check on it. I havent tried that option yet, so i will be playing with it in the next days.

[Lexikos]

Anybody using Autohotkey x64 will have issues with the wrapper because Scintilla is a x32bit only dll.

 

Correction: Scintilla is an open-source source code editing control.

 

My point is that while the main developer of Scintilla may provide a pre-compiled 32-bit dll, he also provides other binaries, and compiling Scintilla for 64-bit isn't difficult.  fincs did it for SciTE4AutoHotkey, though I think he may have since abandoned the 64-bit build.

[Ronins]

For the first issue I have confirmed that it is a bug, even though i do not understand what you mean by "typing fast" because if you are getting the whole line it doesnt matter how fast you type. I did however found that the error shows only in the LAST line of a file, so if your file has 4 lines, lines 1-3 will behave normally but line 4 would append a random number at the end.

I also found that if you put a new line in the last line, that random number will dissapear. I will try to see what causes it.

Thanks for the fix, I do have to add a few manual buffers and I can only add them when I, or sombody else uses the function and tell me that it needs a buffer because i havent read the whole scintilla documentation... yet... hehehe, so thanks again!

for the last point I will have to check on it. I havent tried that option yet, so i will be playing with it in the next days.

 

Hey, here is a sample code to emulate the error i am facing in first problem. I found other method to do this (point 2), but i am still reporting it, just in case..

#include SCI.ahk
#singleinstance force

Gui +LastFound
sci := new scintilla(WinExist())
Gui, Show, w600 h400
return

GuiClose:
ExitApp



Space::
sci.GetLine(0, myvar)
ToolTip % myvar
return

------------------------------------------------------------------------------------------------------

 

As for the third issue, thanks for looking into it. I also found Neil's reply to a similar post, here is the link,

https://groups.google.com/forum/?fromgroups#!topic/scintilla-interest/hgJaj5Vui50

------------------------------------------------------------------------------------------------------

 

Regards

[RaptorX]

Correction: Scintilla is an open-source source code editing control.
 
My point is that while the main developer of Scintilla may provide a pre-compiled 32-bit dll, he also provides other binaries, and compiling Scintilla for 64-bit isn't difficult.  fincs did it for SciTE4AutoHotkey, though I think he may have since abandoned the 64-bit build.

 
It indeed is, I think I misused the word "Scintilla" in this case, because what i meant to say was "My compiled version of Scintilla".
I do remember reading in the mail lists some bugs related to a x64 version of scintilla and that the main developer was not interested on that so basically I there is no direct support from Neil on x64 related stuff i guess. But that might be incorrect.
 

Hey, here is a sample code to emulate the error i am facing in first problem. I found other method to do this (point 2), but i am still reporting it, just in case..

#include SCI.ahk
#singleinstance force

Gui +LastFound
sci := new scintilla(WinExist())
Gui, Show, w600 h400
return

GuiClose:
ExitApp



Space::
sci.GetLine(0, myvar)
ToolTip % myvar
return

------------------------------------------------------------------------------------------------------
 
As for the third issue, thanks for looking into it. I also found Neil's reply to a similar post, here is the link,

https://groups.google.com/forum/?fromgroups#!topic/scintilla-interest/hgJaj5Vui50

------------------------------------------------------------------------------------------------------
 
Regards

Actually that last link you provided already has the answer, but as any good programmer the answer was so compact and optimized that you only understand it if you have already worked with that type of stuff... haha (took me a while to get it)

So basically No you cannot do what you want to do on the Third issue without some manual labor.
You will have to use an image processing program and create a custom marker... so let me back up for a second here.

You know that scintilla has line markers, the default ones that you can use look like a circle filled with a color IIRC and some other plain boring markers as triangles and what not, but they usually get the job done... Scintilla offers the possibility for you to use your own custom markers which must be PixMap files (little research might help you there)...

So you go ahead and create a semi-transparent marker that is the size of the margin (you know the margin width already as you can set it yourself, but i am not sure of the height) and then track the caret (just get which line the caret is at) and place your semi-transparent marker on that line...

thats the idea, you first will have to find out how to create a custom pixmap marker and i can continue helping you from there.

[maestrith]

Cool wrapper I looked at your ignore directory...it was like I was peeking behind the curtain  Much more comprehensive than my wrapper.

[RaptorX]

I remember borrowing the idea of being able to allow calling functions by their IDs from you...
my wrapper does the sci.2256(unused, true) thingy from yours

You helped a lot on few things so as usual feel free to give advice/criticism. It is always welcome. ^^

and about the ignored folder it is like a temporal place to put stuff that dont directly belong on the wrapper and where i keep my ideas/todo list

[maestrith]

I am very interested in the __sciNotify(wParam, lParam, msg, hwnd) function.  I usually deal with notifications on individual basis (each message has a set function) which can be a bit messy.  I am going to give your method a try.  Very clean.

[RaptorX]

indeed... even though while this method works for 90%+ of the functions, there are still a few that require "manual" labor, specially those that need text buffers as you can see in my code, so be careful with it, it is "clean" but it is a minefield.

[Ronins]

 
It indeed is, I think I misused the word "Scintilla" in this case, because what i meant to say was "My compiled version of Scintilla".
I do remember reading in the mail lists some bugs related to a x64 version of scintilla and that the main developer was not interested on that so basically I there is no direct support from Neil on x64 related stuff i guess. But that might be incorrect.
 

Actually that last link you provided already has the answer, but as any good programmer the answer was so compact and optimized that you only understand it if you have already worked with that type of stuff... haha (took me a while to get it)

So basically No you cannot do what you want to do on the Third issue without some manual labor.
You will have to use an image processing program and create a custom marker... so let me back up for a second here.

You know that scintilla has line markers, the default ones that you can use look like a circle filled with a color IIRC and some other plain boring markers as triangles and what not, but they usually get the job done... Scintilla offers the possibility for you to use your own custom markers which must be PixMap files (little research might help you there)...

So you go ahead and create a semi-transparent marker that is the size of the margin (you know the margin width already as you can set it yourself, but i am not sure of the height) and then track the caret (just get which line the caret is at) and place your semi-transparent marker on that line...

thats the idea, you first will have to find out how to create a custom pixmap marker and i can continue helping you from there.

 

I know i'd need pixmaps for it. But thing is, I have no idea how pixmaps will work... I tried this, but couldnt obtain any result..

XFACE := ["48 4 2 1", "a c #ffffff", "b c #000000", "abaabaababaaabaabababaabaabaababaabaaababaabaaab", "abaabaababaaabaabababaabaabaababaabaaababaabaaab", "abaabaababaaabaabababaabaabaababaabaaababaabaaab", "abaabaababaaabaabababaabaabaababaabaaababaabaaab"]
SCI.MARKERDEFINEPIXMAP(25, XFACE)
SCI.MARKERADD(0, 25)

the XFACE is XPM formatted text, as required in Pixmaps. I copied that one from wikipedia

[RaptorX]

Sorry I took so long to reply. I have been out of town for a whole month.
I will try on my own to see how it works and then get back to you.

[Pulover]

Hello RaptorX,

 

This is an amazing work. Thank you.

 

I'm planning to use this class in my project but I'd like have it working correctly in 64-bit as well.

I've download a x64 compiled SciLexer.dll and ran the examples, everything seems to be working except for notifications and syntax highlighting. The latter is the reason I want to use it so I'd like to know if you think it's possible.

[Lexikos]

The error appears to be that all fields of the notification structure are assumed to be the size of a pointer.  You can use the following for reference; it is from my own Scintilla wrapper, which works on x64:

hwndFrom             : [A_PtrSize*0 +  0,  "ptr"],
idFrom               : [A_PtrSize*1 +  0, "uptr"],
code                 : [A_PtrSize*2 +  0, "uint"],
position             : [A_PtrSize*3 +  0,  "int"],
ch                   : [A_PtrSize*3 +  4,  "int"],
modifiers            : [A_PtrSize*3 +  8,  "int"],
modificationType     : [A_PtrSize*3 + 12,  "int"],
text                 : [A_PtrSize*3 + 16,  "str"],
length               : [A_PtrSize*4 + 16,  "int"],
linesAdded           : [A_PtrSize*4 + 20,  "int"],
message              : [A_PtrSize*4 + 24,  "int"],
wParam               : [A_PtrSize*5 + 24, "uptr"],
lParam               : [A_PtrSize*6 + 24,  "ptr"],
line                 : [A_PtrSize*7 + 24,  "int"],
foldLevelNow         : [A_PtrSize*7 + 28,  "int"],
foldLevelPrev        : [A_PtrSize*7 + 32,  "int"],
margin               : [A_PtrSize*7 + 36,  "int"],
listType             : [A_PtrSize*7 + 40,  "int"],
x                    : [A_PtrSize*7 + 44,  "int"],
y                    : [A_PtrSize*7 + 48,  "int"],
token                : [A_PtrSize*7 + 52,  "int"],
annotationLinesAdded : [A_PtrSize*7 + 56,  "int"],
updated              : [A_PtrSize*7 + 60,  "int"]

In case you haven't guessed, the array on each line contains the offset and type of each field.

[Pulover]

Thanks for helping, Lexikos.

 

That solved the notifications issue, but still won't get highlighting to work. I tried to debug __sendEditor to look for any inconsistency but everything seems to be the same (except for the DllCall ErrorLevel that returns A16 in x86 and 0 in x64, but I don't know what this means or even if it's relevant). Does it work for you (or in your wrapper)?

 

[RaptorX]

Thanks for helping, Lexikos.
 
That solved the notifications issue, but still won't get highlighting to work. I tried to debug __sendEditor to look for any inconsistency but everything seems to be the same (except for the DllCall ErrorLevel that returns A16 in x86 and 0 in x64, but I don't know what this means or even if it's relevant). Does it work for you (or in your wrapper)?

interesting, A16 means that dllcall was passed too many parameters or that you need to use the "Cdecl" option while calling... on the other hand 0 means success... i would have expected a 0 in x86 and A16 on x64... are you sure it is the other way around?