Leaderboard

I fully agree with you, that the Byte Order Mark can become a pitfall. With my comment "In general, however, a Byte Order Marking is not a negative feature... " I only intended to avoid the impression, that BOM's are something "bad" at all. As we know from many posts, the whole topic is confusing enough already, especially for newcomers .

#include <GuiMenu.au3> #include <GUIConstantsEx.au3> #include <WinAPI.au3> #include <WindowsConstants.au3> Global Enum $idOpen = 1000, $idSave, $idInfo, $idSub1, $idSub2 Global $GUI, $listview, $hMenu _Main() Func _Main() ; Create GUI $GUI = GUICreate("Menu", 400, 300) $listview = GUICtrlCreateListView("test1|test2|test3|test4", 5, 5, 390, 290) GUICtrlCreateListViewItem("item1|item2|item3|item4", $listview) GUICtrlCreateListViewItem("test1|test2|test3|test4", $listview) ; ----- Create subitem menu ----- $hSubItems1 = _GUICtrlMenu_CreateMenu() _GUICtrlMenu_InsertMenuItem($hSubItems1, 0, "SubItem &1", $idSub1) _GUICtrlMenu_InsertMenuItem($hSubItems1, 1, "SubItem &2", $idSub2) ; ------------------------------- $hMenu = _GUICtrlMenu_CreatePopup() _GUICtrlMenu_InsertMenuItem($hMenu, 0, "Open", $idOpen) _GUICtrlMenu_InsertMenuItem($hMenu, 1, "Save", $idSave) _GUICtrlMenu_InsertMenuItem($hMenu, 2, "Info", $idInfo) _GUICtrlMenu_InsertMenuItem($hMenu, 3, "", 0) _GUICtrlMenu_InsertMenuItem($hMenu, 4, "More", 0, $hSubItems1) ; <---- append subitems here ; Register message handlers GUIRegisterMsg($WM_NOTIFY, "WM_NOTIFY") GUIRegisterMsg($WM_COMMAND, "WM_COMMAND") GUISetState() ; Loop until user exits Do Until GUIGetMsg() = $GUI_EVENT_CLOSE EndFunc ;==>_Main Func WM_NOTIFY($hWnd, $iMsg, $iwParam, $ilParam) Local $iIDFrom, $iCode, $tNMHDR, $tInfo $tNMHDR = DllStructCreate($tagNMHDR, $ilParam) $iIDFrom = DllStructGetData($tNMHDR, "IDFrom") $iCode = DllStructGetData($tNMHDR, "Code") Switch $iIDFrom Case $listview Switch $iCode Case $NM_CLICK, $NM_RCLICK $tInfo = DllStructCreate($tagNMLISTVIEW, $ilParam) If DllStructGetData($tInfo, "Item") > -1 Then _GUICtrlMenu_TrackPopupMenu($hMenu, $GUI) EndIf EndSwitch EndSwitch Return $GUI_RUNDEFMSG EndFunc ;==>WM_NOTIFY Func WM_COMMAND($hWnd, $iMsg, $iwParam, $ilParam) Switch $iwParam Case $idOpen _WinAPI_ShowMsg("Open") Case $idSave _WinAPI_ShowMsg("Save") Case $idInfo _WinAPI_ShowMsg("Info") ; ---- submeenus ---- Case $idSub1 _WinAPI_ShowMsg("submenu1") Case $idSub2 _WinAPI_ShowMsg("submenu2") EndSwitch EndFunc ;==>WM_COMMAND

Thanks @Musashi, but I'd like to mention one thing: It can be a negative feature in some contexts, especially for UTF-8 is supposed to be backward compatible with ASCII but adding a BOM breaks that compatibility, and for this reason the Unicode standard neither recommends nor prohibits addition of the BOM. This section from the Wikipedia article for UTF-8 explains it very well:

I don't know why the DEP flag is not set by Aut2Exe for 32 bit executables, but a quick-n-dirty workaround would be to create a 64-bit executeable, because the DEP flag is enabled by default for these (Windows does that). Another option, if you need 32-bit: Download Visual Studio (Community Edition) and use editbin.exe to set the DEP flag for your 32-bit executable. Beware, that this is a crazy 10 Gbyte download (you'll need the C++ build tools), just for that single file editbin.exe Path for both files: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\Hostx64\x86> check DEP dumpbin /headers | find "NX compatible" check ASLR  dumpbin /headers | find "Dynamic base" set DEP editbin /NXCOMPAT file.exe set ASLR editbin /DYNAMICBASE file.exe Br Kurt

@TheDcoder is right (as almost always ). AFAIK IniRead based on the Windows function GetPrivateProfileString (A/W ?) from the Kernel32.dll and is capable of processing both ANSI and UNICODE. The problem with parsing an .ini file is just the Byte Order Mark at the beginning. For example, if the first line is a comment, such as ; My ini file V 2.1.5 [Section1] Key=value ... then the [Section1] will be read without any problems, because the comment line starts with the BOM and will be ignored anyway. In general, however, a Byte Order Marking is not a negative feature, as it allows the character encoding to be determined unambiguously. With ANSI and UTF-8, for example, this is not so easy.