The MASM Forum
Projects => MASM32 => Topic started by: zedd151 on August 29, 2015, 04:46:34 AM
-
Is this a qeditor issue, or an I doing something wrong here?
I am writing a qe plugin using the legacy interface, and trying to change the color
of the selected text. Using this little function should do the trick. I used a
custom version of 'riched.asm' as a testbed, and I can change text color there
without problems. But when calling SetColor from the plugin interface, the color
of the selected text does not change as it should. The background color changes
just fine with the SendMessage call. But that is not what I want. I only use that
as an example that code inside of 'SetColor' is executing. I am thinking that
the way qeditor is written, maybe there is no way to change the color of only a
portion of the text externally. I CAN change the color of ALL of the text, but
again not really what I wanted.
SetColor proc
LOCAL cfm:CHARFORMAT
invoke SendMessage, hRichEd, EM_SETBKGNDCOLOR, 0, bColor ; <-- this works, so code here is getting executed
invoke RtlZeroMemory, addr cfm, sizeof cfm
mov cfm.cbSize, sizeof cfm
mov cfm.dwEffects, CFM_COLOR
mov cfm.dwMask, CFM_COLOR
mov cfm.crTextColor, tColor ; <-- while this one does not
invoke SendMessage, hRichEd, EM_SETCHARFORMAT, SCF_WORD or SCF_SELECTION, addr cfm
; the only other optin is:
; invoke SendMessage, hRichEd, EM_SETCHARFORMAT, SCF_ALL, addr cfm - which is NOT
; what I would want. I only want to change the text color of the selected text.
ret
SetColor endp
-
Without seeing complete code, it's difficult to find the bug.
Do you have invoke SendMessage, hEdit, EM_SETTEXTMODE, TM_RICHTEXT, 0 somewhere?
-
Sorry for the long delay, my ISP is acting a little loopy.
The connection at times is Veeeerrrry slow - life of the fringes of wifi.
include \masm32\include\masm32rt.inc
LibMain PROTO :DWORD,:DWORD,:DWORD
QePlugIn PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD
.code
LibMain proc hInstDLL:DWORD, reason:DWORD, unused:DWORD
.if reason == DLL_PROCESS_ATTACH
return TRUE
.endif
ret
LibMain Endp
QePlugIn proc hInst:DWORD,hMain:DWORD,hEd:DWORD,hTool:DWORD,hStat:DWORD
LOCAL hMem:DWORD
LOCAL Cr:CHARRANGE
LOCAL cfm:CHARFORMAT, tmpsize:dword
invoke SendMessage, hEd, EM_EXGETSEL, 0, ADDR Cr
mov eax, Cr.cpMin
mov edx, Cr.cpMax
sub edx, eax
stralloc edx
mov hMem, eax
invoke SendMessage,hEd,EM_GETSELTEXT,0,hMem
mov esi, hMem
tippy:
mov al, [esi]
cmp al, 0
jz outta
cmp al, 9
jnz @f
mov byte ptr [esi], 20h
inc esi
jmp tippy
@@:
inc esi
jmp tippy
outta:
invoke SendMessage, hEd, EM_REPLACESEL, 1, hMem
invoke lstrlen, hMem
mov tmpsize, eax
mov eax, Cr.cpMin
add eax, tmpsize
mov Cr.cpMax, eax
invoke SendMessage, hEd, EM_EXSETSEL, 0, ADDR Cr
invoke RtlZeroMemory, addr cfm, sizeof cfm
mov cfm.cbSize, sizeof cfm
mov cfm.dwMask, CFM_COLOR
m2m cfm.crTextColor, 00007FFFh
invoke SendMessage, hEd, EM_SETCHARFORMAT, SCF_WORD or SCF_SELECTION, addr cfm
strfree hMem
Bye:
ret
QePlugIn endp
End LibMain
Heres a simple one replaces tabs w 4 spaces. the plug itself works fine.
just I can't highlight like I want.
** I had to go back and edit because of sloppy copy/paste oops.
I tried to run what I had posted it crashed spectacularly.
Now it's the right code above.
-
That is a modified version, I had overwritten the original by mistake.
Anyway this one doen't call SetColor rather the functions of SetColor ae integrated .
If you change SCF_WORD or SCF_SELECTION to SCF_ALL, the entire text color changes.
-
No EM_SETTEXTMODE message??
-
No EM_SETTEXTMODE message??
I tried it before and after
"invoke SendMessage, hEd, EM_SETCHARFORMAT, SCF_WORD or SCF_SELECTION, addr cfm"
I don't think I should need that anyway. I made a test with riched.asm from the masm32 examples
and the selected text color changes with just the EM_SETCHARFORMAT message.
So, I might just give up for time being.
I am planning on making a program to automate the process of creating plugins for qe.
The text highlighting was just a side job from my other goals.
But thanks for the help.
-
Z,
The guts of QE are reasonably complicated and the message you are trying to use are used internally by QE so the mod you are trying to do will keep being over written. Don't be afraid to use the later plugin interface its a bit more flexible than the old one.
-
... used internally by QE so the mod you are trying to do will keep being over written. ...
thanks hutch, I kinda figured that. But needed verification.
I will look at the newer interface.
-
So I am looking at the 'new' plugin interface, I have a question for hutch...
It all looks okay, but looks like 3 is missing.
push 3 does return some address it appears, my
question is what is it?
Or is it an intentional omission?
Just curious. Don't really need to know esp. if it is for internal purposes.
; ~ ~ ~ ~ snip ~ ~ ~ ~
GethEdit MACRO
push 2 ; <---- rich edit
call QEinterface
EXITM <eax>
ENDM
; GethUnknown MACRO
; push 3 == ?? ; <---- missing, or ??
; call QEinterface
; EXITM <eax>
; ENDM
GethToolBar MACRO
push 4 ; <---- tool bar
call QEinterface
EXITM <eax>
ENDM
; ~ ~ ~ ~ snip ~ ~ ~ ~
zedd
-
Z,
The help file for QE shows the range of data that can e obtained from QE.
0 = The instance handle.
1 = Main window handle for QE.
2 = The edit control handle for the main edit window.
3 = Reserved.
4 = The toolbar handle.
5 = The status bar handle.
6 = The menu handle.
As you would gather the interface had to be written into QE and the published access is all there is. Getting each handle from a DLL should allow you to write more or less anything you want from processing data in the editor to writing to the status bar, adding bits to the menus and so on but be aware that as a DLL has direct binary access into QE, if you make a mess of it you can crash QE and there is little that can be done to prevent it.
-
... 3 = Reserved....
Kinda thought so, thanks.
-
I have been wanting to explore the other options available through the qeditor plugin interface.
Is it possible to have more than one plugin running at the same time?
I was thinking about making a custom toolbar for qe, that would have to be
running almost all the time. Also, I wanted to be able to still use the
plugins as well. Perhaps using the "PiEntryPoint" procedure for
the toolbar, then using "QePlugIn" as the handler for the plugins.
The toolbar would be a 'floating' toolbar, dialog box maybe.
What I mean is I know I can't open two instances of PiEntryPoint at the same time,
or two instances of QePlugin; but maybe one of each. unless of course it would cause
internal conflicts inside of qeditor.
zedd