Uploaded a new version of the SciTE4AutoIt3.exe v21.316.1639.1

[Jos]

It looks like this does change the setting for  "check.if.already.open":

$hScite_Dir = WinGetHandle("DirectorExtension")

SendSciTE_Command($My_Hwnd, $hScite_Dir, 'askproperty:check.if.already.open')
SendSciTE_Command($My_Hwnd, $hScite_Dir, 'extender:dostring props["check.if.already.open"]=0')
SendSciTE_Command($My_Hwnd, $hScite_Dir, 'askproperty:check.if.already.open')

If not supply me with a test script that demonstrates the issue so I can see what is happening.  

Jos

Edited April 16, 2021 by Jos

[argumentum]

expandcollapse popup

#include <Debug.au3>
#include <WinAPIProc.au3>


If Not StringInStr($CmdLineRaw, "/ErrorStdOut") Then Exit MsgBox(0, @ScriptName, "Please run from SciTE.", 10)
;~ Exit _DebugArrayDisplay(SciTE_FindRunningSessions()) ; testing

Example()
Func Example()
    Local $aRunningScites = SciTE_FindRunningSessions()
    If Not @extended Then
        MsgBox(0, @ScriptName, "Could not find a running SciTE !!!", 10)
        Return SetError(@error, @extended, $aRunningScites)
    EndIf
    Local $iActive = 1
    For $n = 1 To $aRunningScites[0][0]
        If $aRunningScites[$n][4] Then $iActive = $n
    Next
    If Not FileGetSize($aRunningScites[$iActive][5]) Then Return MsgBox(0, @ScriptName, "can't find SciTE", 10)
    Local $My_Hwnd = GUICreate("AutoIt3-SciTE interface")
    GUIRegisterMsg(74, "MY_WM_COPYDATA")
    Local $hScite_Dir = $aRunningScites[$iActive][3]

    SendSciTE_Command($My_Hwnd, $hScite_Dir, 'askproperty:check.if.already.open')
    SendSciTE_Command($My_Hwnd, $hScite_Dir, 'extender:dostring props["check.if.already.open"]=0')
    SendSciTE_Command($My_Hwnd, $hScite_Dir, 'askproperty:check.if.already.open')

    Sleep(300)
    ; this should open another SciTE session, but does not.
    ; all it does is disable the menu control
    ; even tho it returns acknowledgment of the setting   =(...
    Local $iNewPID = ShellExecute($aRunningScites[$iActive][5], '"' & @ScriptFullPath & '"')
    ConsoleWrite("-   $iNewPID = " & $iNewPID & @CRLF)

    ProcessWaitClose($iNewPID, 3) ; it closes itself as it handled the script to this session.

    Local $iProcessExists = ProcessExists($iNewPID)
    ConsoleWrite(($iProcessExists ? '-' : '!') & "   ProcessExists($iNewPID) = " & $iProcessExists & @CRLF)
EndFunc   ;==>Example


Func SciTE_FindRunningSessions()
    ; I know that all this is an overkill, instead of just:
    ; $hScite_Dir = WinGetHandle("DirectorExtension")
    ; but I needed it to be like this for the demostration
    ; to work anywhere.

    Local $aProcessList = ProcessList()
    If @error Or UBound($aProcessList) = 0 Then
        Local $aReturn[1][6] = [[0, "ERROR"]]
        Return SetError(1, 0, $aReturn)
    EndIf
    Local $aProcessWindows, $iCount = 0, $hSciTEWindow_hwd, $hDirectorExtension_hwd
    Local $aReturn[UBound($aProcessList) + 1][6] = [[0, "PID", "hSciTEWindow_hwd", "hDirectorExtension_hwd", "[Active]", "ProcessFileName"]]
    For $n = 1 To UBound($aProcessList) - 1
        If StringInStr($aProcessList[$n][0], "SciTE") = 1 And StringInStr($aProcessList[$n][0], ".exe") Then
            $hSciTEWindow_hwd = 0
            $hDirectorExtension_hwd = 0
            $aProcessWindows = _WinAPI_EnumProcessWindows($aProcessList[$n][1], 0)
            For $m = 1 To UBound($aProcessWindows) - 1
                If $aProcessWindows[$m][1] = "SciTEWindow" Then $hSciTEWindow_hwd = $aProcessWindows[$m][0]
                If $aProcessWindows[$m][1] = "DirectorExtension" Then $hDirectorExtension_hwd = $aProcessWindows[$m][0]
            Next
            If $hSciTEWindow_hwd And $hDirectorExtension_hwd Then
                $iCount += 1
                $aReturn[$iCount][0] = $aProcessList[$n][0]
                $aReturn[$iCount][1] = $aProcessList[$n][1]
                $aReturn[$iCount][2] = $hSciTEWindow_hwd
                $aReturn[$iCount][3] = $hDirectorExtension_hwd
                $aReturn[$iCount][4] = (WinActive("") = $hSciTEWindow_hwd ? 1 : 0)
                $aReturn[$iCount][5] = _WinAPI_GetProcessFileName($aProcessList[$n][1])
            EndIf
        EndIf
    Next
    ReDim $aReturn[$iCount + 1][6]
    $aReturn[0][0] = $iCount
    Return SetError(0, $iCount, $aReturn)
EndFunc   ;==>SciTE_FindRunningSessions

Func SendSciTE_Command($My_Hwnd, $Scite_hwnd, $sCmd)
    Local $My_Dec_Hwnd = Dec(StringRight($My_Hwnd, 8))
    $sCmd = ":" & $My_Dec_Hwnd & ":" & $sCmd
    ConsoleWrite('-->' & $sCmd & @LF)
    Local $CmdStruct = DllStructCreate('Char[' & StringLen($sCmd) + 1 & ']')
    DllStructSetData($CmdStruct, 1, $sCmd)
    Local $COPYDATA = DllStructCreate('Ptr;DWord;Ptr')
    DllStructSetData($COPYDATA, 1, 1)
    DllStructSetData($COPYDATA, 2, StringLen($sCmd) + 1)
    DllStructSetData($COPYDATA, 3, DllStructGetPtr($CmdStruct))
    DllCall('User32.dll', 'None', 'SendMessage', 'HWnd', $Scite_hwnd, _
            'Int', 74, 'HWnd', $My_Hwnd, _
            'Ptr', DllStructGetPtr($COPYDATA))
;~  ConsoleWrite('SendSciTE_Command @error = ' & @error & @CRLF)
EndFunc   ;==>SendSciTE_Command

; Received Data from SciTE
Func MY_WM_COPYDATA($hWnd, $msg, $wParam, $lParam)
    Local $COPYDATA = DllStructCreate('Ptr;DWord;Ptr', $lParam)
    Local $SciTECmdLen = DllStructGetData($COPYDATA, 2)
    Local $CmdStruct = DllStructCreate('Char[' & $SciTECmdLen + 1 & ']', DllStructGetData($COPYDATA, 3))
    Local $SciTECmd = StringLeft(DllStructGetData($CmdStruct, 1), $SciTECmdLen)
    ConsoleWrite('<--' & StringFormat($SciTECmd) & @LF)
EndFunc   ;==>MY_WM_COPYDATA

This should run anywhere and show not to open a new SciTE.

Edited April 17, 2021 by argumentum

[Jos]

Ok, I think I understand your issue now: The setting is nicely changed in memory for the existing proces,  but the new shelled instance of SciTE will check de properties files  and still read the "check.if.already.open=1" setting, thus detect the other instance and close itself after having forwarded the info of the "file to open".

This is a POC script that will open a new session by temporarily updating the SciTEUser.properties:

$SciTE = "C:\Program Files (x86)\AutoIt3\SciTE\SciTE.exe"
$TestAu3 = "D:\temp\test.au3"

$SciTEUserConfig = "C:\Users\jvdza\AppData\Local\AutoIt v3\SciTE\SciTEUser.Properties"
$SciteConfigContent = FileRead($SciTEUserConfig)
$rc=FileWrite($SciTEUserConfig ,@crlf & "check.if.already.open=0" & @CRLF)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $rc = ' & $rc & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
Run($SciTE & " " & $TestAu3)
FileRecycle($SciTEUserConfig)
$rc=FileWrite($SciTEUserConfig ,$SciteConfigContent)

 Jos

[argumentum]

SendSciTE_Command($My_Hwnd, $hScite_Dir, "menucommand:416") ; IDM_READONLY=416       ; this does as expected
    SendSciTE_Command($My_Hwnd, $hScite_Dir, "menucommand:413") ; IDM_OPENFILESHERE=413  ; this does not

...this is deeper than the string setting representation of the byte that keeps/does the setting, as clicking the menu works as advertised, without SciTE writing to .properties .
SciTE reading the .properties for the decision on loading, is an assumption that proves not to be so.
Temporarily patching the .properties will have to do until it gets fixed and recompiled, but is not like is a must for everyday usage, so no hurry.
And surely is something to ask SciTE developers to look at, as is not related to the AutoIt adaptation.

Last but not least, thanks for attending to my questions. I know I come up with some uncommon ones
 

[Jos]

1 hour ago, argumentum said:

...this is deeper than the string setting representation of the byte that keeps/does the setting, as clicking the menu works as advertised, without SciTE writing to .properties .
SciTE reading the .properties for the decision on loading, is an assumption that proves not to be so.

Not Sure I understand your reasoning: Aren't those settings just for the current instance of SciTE where as the "check.if.already.open" is checked in a new instance of SciTE?

[argumentum]

in "SciTE_lite", without a .properties file, the same behavior can be observed.
"check.if.already.open" is not the setting, actually, not a setting. Is a verbal notation.
In fact you can send:

SendSciTE_Command($My_Hwnd, $hScite_Dir, 'askproperty:check.if.raining.elsewhere')
    SendSciTE_Command($My_Hwnd, $hScite_Dir, 'extender:dostring props["check.if.raining.elsewhere"]=2')
    SendSciTE_Command($My_Hwnd, $hScite_Dir, 'askproperty:check.if.raining.elsewhere')

and it'll say, "ok, I'll take it", "set to 2", but is not mapped to anything. Same with "check.if.already.open", I believe that internally, this setting got lost and no one ever cared to even know that is not working. But I have not read the code to say with any certainty what is exactly going on. I assume that is along those lines.

I believe that since the loading of the setting from file works as it should and that the menubar is working as it should, this bug would not come up to most ppl, not until I 

This is something to be debugged in the source of SciTE. I don't know, all I can do is observe GUI behavior compared to command behavior. My "lingo" is not of a programmer but I don't know how to better explain my understanding. You can go and click the menu and read the files and come up with the same understanding. Good luck Jim ?.  

 

[Jos]

27 minutes ago, argumentum said:

In "SciTE_lite", without a .properties file, the same behavior can be observed.

This isn't true as the properties files are merged into the PE Header as Embedded PROPERTIES, as you can see:

  

and you can set any variable you choose in the properties for your own purpose as we have done with our setup.
So I still am pretty sure that what I have explained before, is how things are working unless somebody can demonstrate otherwise.  

Jos  

Edited April 17, 2021 by Jos

[TheDcoder]

Not sure if this is the right place for feature requests, but can we get JavaScript syntax highlighting support in SciTE? I have been working on JS in SciTE and the plain black and white colours are boring in text mode 😪

It is very useful in web automation, some things are impossible without it, so it is appropriate if we add support for JS syntax.

[Jos]

2 hours ago, TheDcoder said:

but can we get JavaScript syntax highlighting support in SciTE?

It is already active for *.js , what is the file extension for the file you are working on?

[TheDcoder]

@Jos ...I am using *.js too, and I also don't see the JavaScript option in the languages. Maybe I am using an old version of SciTE? 😕

[Jos]

The full version works fine. the lite version doesn't. .... you should be able to check which version you have.

[TheDcoder]

@Jos I am using the full version with all the extra features:

Quote

SciTE
32-bit
Version 4.2.0
    Sep  3 2019 19:04:05
by Neil Hodgson.
 Updated by Jos

 

[mLipok]

you are using quite old version....

current is:

Quote

Version 4.4.6 
    Mar 16 2021 13:51:55
by Neil Hodgson.
 Updated by Jos

 

[TheDcoder]

7 minutes ago, mLipok said:

you are using quite old version....

Not really, that version was from November last year (2020). But I have now installed the latest version and do see that JS highlighting is included, but there is no option for it in the menu:

[mLipok]

It would be also nice to have option for XML and JSON.

[TheDcoder]

@mLipok Just use Hypertext for XML and JavaScript for Json 🤣

[Jos]

There is a difference with the lexers shown in the dropdown and the lexers actually supported:

 

... as you can see: JS lexing works fine and F5 runs cscript.  

Edited April 27, 2021 by Jos

[TheDcoder]

@Jos Yes, but can you add the missing options? It's useful if you are creating a new file and don't want to save it immediately... or at all.

I use Geany as my default code editor and it provides this option, very handy.

[Jos]

16 minutes ago, TheDcoder said:

Yes, but can you add the missing options?

Just add whatever you like by modifying your SciteUser.properties  with something like this:

my.languages=\
&js|cpp||

menu.language=$(default.languages)$(my.languages)

You can find the possible options in SciTEGlobal.properties where you each for: default.languages

I don't like to have a long list with possible language options people like to have there as SciTE will use the extension anyway to detect the lexer&properties to use.  

...but your original question was "but can we get JavaScript syntax highlighting support in SciTE? " .... which is the case already...right?

Edited April 27, 2021 by Jos

[TheDcoder]

@Jos Thanks for the instructions.

3 hours ago, Jos said:

I don't like to have a long list with possible language options people like to have there as SciTE will use the extension anyway

This is my personal opinion, but I think this is bad design, it should display all languages that are supported, otherwise it is misleading. This also does not cover the use cases I suggested.

3 hours ago, Jos said:

which is the case already...right?

Yes, just had to update my SciTE installation.