AutoItHelp v3.3.16.1 and v3.3.18.0 with external CSS loading

[argumentum]

2 hours ago, WildByDesign said:

I always call it right after the includes.

The earlier, the better. There is no need to first load #includes. But before creating any GUI stuff.
If you have an experience that pushed you to the advise please share it.

P.S.: where is your update / bettered / 2026 edition of the darkMode_mod.au3 ????, I will need it ( I've grown lazy )  

[WildByDesign]

1 minute ago, argumentum said:

The earlier, the better. There is no need to first load #includes. But before creating any GUI stuff.
If you have an experience that pushed you to the advise please share it.

You are 100% right. The earlier during process init the better. I think the only reason why I had it after includes was more a matter of keeping everything at the top looking clean and tidy. But realistically it should be right at the top, you are right.

5 minutes ago, argumentum said:

P.S.: where is your update / bettered / 2026 edition of the darkMode_mod.au3 ????, I will need it ( I've grown lazy ) 

This is something that should be done. Needs to be done, really. I’m just afraid to step on any “toes” because I believe NoNameCode mentioned getting back into it for another version but also UEZ shared some incredible subclassing code for dark mode. I’m not sure which code would be the best “base code” to start with.

It got much more complicated when it came to applying dark mode to statusbar, menubar, and a few other things. Trying to figure out how to add those methods to a UDF makes my brain start to smoke a bit. Plus having to overpaint that white line in a dark mode menubar.  If organized and done right, it could be really incredible.

We have all of those individual, beautiful pieces to the puzzle. But figuring out how to put that complex puzzle together in a single UDF is something that I may not be skilled enough for.

But I am definitely willing to jump in and help with the dark mode stuff. Even light mode theming has improvements there too, so technically it would be good to run it and have the choice between applying light or dark. 

[argumentum]

Take a look at https://www.autoitscript.com/forum/topic/201673-json-http-post-serverlistener/page/2/#comment-1447447 for a how to JSON - AJAX ( the example on top when running the script ) to give you an idea for the example button(s) that is enclosed in "if (document.URL.match(/^mk:@MSITStore:/i)) {"  

Global $tcp_Port = 80   ; if 80 is in use, try 81, as in http://127.0.0.1:81/home/

that port should read from your ini file for now ( in the example I linked above )

[argumentum]

2 minutes ago, WildByDesign said:

I’m just afraid to step on any “toes” because I believe NoNameCode mentioned getting back into it for another version but also UEZ shared some incredible subclassing code for dark mode. I’m not sure which code would be the best “base code” to start with.

Yes it will be the best, because you are the best  ( don't tell anyone I said that )

An in regards to toes, fvk'em. There are no toes but if any toes popup, add a mention like: "..thanks to the crying baby @userName for parts of the code"  

[WildByDesign]

On 2/16/2026 at 9:49 AM, bladem2003 said:

If you want, you can help me with your suggestion for DPI example scripts.

Yeah I can probably help with that. I'm still trying to think of the best way to do it.

By the way, I'm wondering if we should use GDI Scaling instead of the System DPI scaling. System DPI is better and sharper but can alter the size of controls more. And since it is other, older example scripts we don't exactly want to mess with sizes so much. GDI Scaling will make the text sharp but maintain original sizes.

; High-DPI GDI Scaling to sharper text but keep control size as expected
DllCall("user32.dll", "bool", "SetProcessDpiAwarenessContext", @AutoItX64 ? "int64" : "int", -5)

Try that and let me know what you think.

[WildByDesign]

@bladem2003 I have put quite a lot of thought into how we could add DPI to the examples. I don't think that we should change anything system-wide with the DPI compatibility settings. Also, writing the DPI line to all of the example files would not be great. I don't like the idea of altering the original files.

So have a look at this:

expandcollapse popup

#include <FileConstants.au3>
#include <File.au3>

$sTemplate = _TempFile(@TempDir, "~", ".au3")
ConsoleWrite("temp file: " & $sTemplate & @CRLF)

; DPI line as string
$sDPI = '; High-DPI GDI Scaling to sharper text but keep control size as expected' & @CRLF
$sDPI &= 'DllCall("user32.dll", "bool", "SetProcessDpiAwarenessContext", @AutoItX64 ? "int64" : "int", -5)'

; template file
;$sTemplate = @ScriptDir & "\DPI-template.au3"
$sPath = @ScriptDir & "\AutoitHelpDark2\Examples\Helpfile\GUICtrlCreateListView.au3"

$iFileExists = FileExists($sTemplate)
If Not $iFileExists Then FileWrite($sTemplate, "")

$sFileRead = FileRead($sPath)

; open DPI template
$hFileOpen = FileOpen($sTemplate, $FO_APPEND)

FileWrite($hFileOpen, $sDPI)
FileWrite($hFileOpen, @CRLF & @CRLF)
FileWrite($hFileOpen, $sFileRead)

; close file after writing
FileClose($hFileOpen)

; run Example with DPI
$iPID = ShellExecute($sTemplate)

; wait for Example to be closed
ProcessWaitClose($iPID)

; delete temporary Example file with DPI
FileDelete($sTemplate)

 

[bladem2003]

That looks very good.

It also has the advantage, since it's a temporary file, that you can experiment with the example without changing the original.

[bladem2003]

High-DPI scaling for the GUI and examples thanks @WildByDesign

 

https://www.autoitscript.com/forum/topic/202204-simple-google-translate/

I've included a Google translation for the highlighted text, in case anyone needs it.🤓

Highlight the text and click the language icon in the upper right corner.

 

 

https://limewire.com/d/lNO8X#3en0abdO9R

[WildByDesign]

1 hour ago, bladem2003 said:

High-DPI scaling for the GUI and examples thanks

You're welcome. There was a bug in my implementation though.

We need to set the working directory, since the scripts assume they are working from AutoIt3\Examples\Helpfile. If they come from some of the other folders, we may need to make more changes.

There is also a problem with scripts that have #include "Extras\HelpFileInternals.au3" or #include "Extras\WM_NOTIFY.au3" because they fail to run since we are running from a different directory.

The following example sets the current directory and also replaces the "#include "Extras\" with the appropriate install dir stuff:

(and the example _GUICtrlStatusBar_Resize previously failed. So this should fix that issue.)

expandcollapse popup

#include <FileConstants.au3>
#include <File.au3>

$sTemplate = _TempFile(@TempDir, "~", ".au3")
$sHelpfileDir = StringRegExpReplace(@AutoItExe, '\\[^\\]+$', "") & "\Examples\Helpfile"
$sReplace = '#include "' & $sHelpfileDir & '\Extras\'

; DPI line as string
$sDPI = '; High-DPI GDI Scaling to sharper text but keep control size as expected' & @CRLF
$sDPI &= 'DllCall("user32.dll", "bool", "SetProcessDpiAwarenessContext", @AutoItX64 ? "int64" : "int", -5)' & @CRLF
$sDPI &= "$sHelpfileDir = StringRegExpReplace(@AutoItExe, '\\[^\\]+$', "
$sDPI &= '"") & "\Examples\Helpfile"' & @CRLF
$sDPI &= 'FileChangeDir ($sHelpfileDir)'

; helpfile
$sPath = @ScriptDir & "\AutoitHelpDark2\Examples\Helpfile\_GUICtrlStatusBar_Resize.au3"

$iFileExists = FileExists($sTemplate)
If Not $iFileExists Then FileWrite($sTemplate, "")

$sFileRead = FileRead($sPath)
$sFileRead = StringReplace($sFileRead, '#include "Extras\', $sReplace)

; open DPI template
$hFileOpen = FileOpen($sTemplate, $FO_APPEND)

FileWrite($hFileOpen, $sDPI)
FileWrite($hFileOpen, @CRLF & @CRLF)
FileWrite($hFileOpen, $sFileRead)

; close file after writing
FileClose($hFileOpen)

; run Example with DPI
$iPID = ShellExecute($sTemplate)

; wait for Example to be closed
ProcessWaitClose($iPID)

; delete temporary Example file with DPI
FileDelete($sTemplate)

 

By the way, 0.3 is awesome. I love that you can resize it now. Your GUI is sharp. The examples are sharper also with the GDI scaling. We could apply the regular High DPI but it could mess with control sizes and so on. I think it's perfect the way you have it.

Suggestion: Have a way to resize the font size in your GUI and the web content. Although I would imagine the web content part might be tricky.

The only last remaining concern that I have is how the separator in the web content blanks out anytime you move it (only while it is moving). I don't think that is something that you can fix within your GUI though. Since that separator is part of the web content (javascript I believe), the fix would have to be done there. I personally would not know how to fix it. But something to keep in mind, although certainly a lower priority issue.

[WildByDesign]

@argumentum Are you OK with this newer Helpfile stuff taking place in your thread? Or would you prefer @bladem2003 make a new thread? I just wanted to check in with you on that.

[argumentum]

...I don't mind doing it here or in it's own thread. But @bladem2003's initiative is very different and will confuse future people reading this thread, so in that regard, would be advisable to open threads as needed for the concept of: embedding a website in a embedded browser that interacts with the PC**.

And there a separate aspects to his project, being:
1) The html/JavaScript runs on a HTTP daemon. That will take a TCP hat.
2) The html/JavaScript will need heavy work. That will take a JavaScript hat.
3) The AJAX ( or what not ) and the SciTE interaction, will take an IPC hat.
4) The embedded browser will need options for Win7 ( and XP would be great ) but default to the better technology available on the OS, in case WebView2 is not possible on the user's PC, and that will take that hat.

So that will be a few threads to be called ( in my way of naming things ) : "CHMless Help: The site", "CHMless Help: The browser", "CHMless Help: The integration". Am just thinking on my feet right now but that would keep each thread for each aspect clear and concise for anyone reading and collaborating on the project on it's own area of expertise

I tend to over engineer stuff and uselessly complicate everything so, you all that are actively dedicating time to bring the idea to fruition, have a chat, maybe via PM/DM and ask each other what each will be participating in, because this is a larger, more involved project.***
Or open a thread in "AutoIt Projects and Collaboration" and announce the project, the pressing reasons behind it, and the need for talented people to bring it to life ( newbies accepted )  

At the high CPU/time price of single file, a ZIP ( of sorts ) that contains all the files and is read by the HTTP daemon. And that too would be nice but it may take ASM to work fast in AutoIt. But that is a project of it's own. Responsiveness at the speed of the current CHM is the goal for now.

**The PC interaction would benefit if a gray-hat is worn. Once this is a product, can it be easily abused ( hacked ) from outside the local PC ?, about from the inside, what are the risks ?. That too needs attention in this project.

***So, if you don't know how to do something, but are willing to learn, just go at it. Anyone would benefit from gaining experience in new things ( that are likely to expand one's previous capabilities )  

Ok. I guess I just loaded you with the fear of god coding