40 replies to this topic

[Coco]

That's a good option, let the user specify a handler(function)...

[fincs]

That's a good option, let the user specify a handler(function)...

No, you misunderstand; I'm talking about executing the g-label in a similar way to how OnMessage handlers execute their functions (the internal implementation, that is); and it does not involve re-sending/posting the message.

[Coco]

I see, I look forward to how it turns out...what are the possible side-effects though?

[fincs]

what are the possible side-effects though?

As far as I understand none. If OnMessage WM_NOTIFY handlers have always worked without hanging the script, this approach should also work.

[Coco]

I guess it's the best option...

[fincs]

Ok, I just fixed it.

[Coco]

fincs: Where can I download the updated .exe?

[fincs]

fincs: Where can I download the updated .exe?

You'll have to wait for Lexikos to update the alpha, as I believe he wouldn't want people posting random binaries.

[Lexikos]

v1.1.10-alpha2 uploaded; includes fincs' fix.

[Zaelia]

Thank you very much. Sound managment has an ease of use for win6+ users.

[Coco]

In most instances, some commands and also control flow statement(s [specifically if-else], within the subroutine of the control's associated target label(g-Label), resulted to some weird behavior. Tested on ComboBoxEx, (not sure if it's due to A_GuiEvent representing varied control-specific structs depending on the notification, NMHDR is always the first member though). Every time a notification is sent via WM_NOTIFY, opening the ComboBoxEx's dropdown listbox would cause it to slide up an down repeatedly before settling to a halt. Then it would need to clicks to select an item. Removing the g-label fixes this though.

[just me]

What about using the well-tried PostMessage method with

• WM_COMMAND : A_GuiEvent = "WM_COMMAND" or "C", A_EventInfo = HIWORD(wParam)
• WM_NOTIFY  : A_GuiEvent = "WM_NOTIFY"  or "N", A_EventInfo = code field of NMHDR structure

If one wants to get more informations on specific notifications OnMessage() will accomplish that and additionally allow to return a specific value when needed.

[fincs]

If one wants to get more informations on specific notifications OnMessage() will accomplish that and additionally allow to return a specific value when needed.

The point of this built-in support is precisely not needing to use DllCall or OnMessage (especially since the latter always captures messages for all windows and there's no HWND filtering system).

Also, currently this is calling the subroutine in a similar way to how OnMessage() dispatches message handlers, so in theory there shouldn't be "weird behaviour" (I personally haven't been able to reproduce what Coco is seeing; possibly it's a bug in his script) unless I'm missing something.

EDIT: by the way, could you post here a test case for the so-called "weird behaviour"?

[just me]

... and additionally allow to return a specific value when needed.

How could this be done with your attempt?

 

BTW: If Custom controls will be implemented, it's time to implement "on control" message handlers.

[fincs]

How could this be done with your attempt?

Currently zero is always returned, although it could be changed so that ErrorLevel is returned to the message sender. Most controls appear to ignore the return value of WM_NOTIFY so this should not be an issue.

BTW: If Custom controls will be implemented, it's time to implement "on control" message handlers.

It would be certainly useful to have per-window OnMessages.

EDIT: Lexikos, would this be OK?
EDIT2: Simplified approach.

Spoiler

script_gui.cpp:

@@ -8264,12 +8264,11 @@ LRESULT CALLBACK GuiWindowProc(HWND hWnd, UINT iMsg, WPARAM wParam, LPARAM lPara
 				if (!*item.szUrl || !g_script.ActionExec((LPTSTR)(LPCTSTR)CStringTCharFromWCharIfNeeded(item.szUrl), NULL, NULL, false))
 					pgui->Event(control_index, nmhdr.code, GUI_EVENT_NORMAL, item.iLink + 1); // Link control uses 1-based index for g-labels
 			}
 			return 0;
 		case GUI_CONTROL_CUSTOM:
-			pgui->Event(control_index, nmhdr.code, GUI_EVENT_NONE, (UINT_PTR) &nmhdr);
-			return 0;
+			return pgui->CustomCtrlWmNotify(control_index, &nmhdr);
 		case GUI_CONTROL_STATUSBAR:
 			if (!(control.jump_to_label || (control.attrib & GUI_CONTROL_ATTRIB_IMPLICIT_CANCEL)))// These is checked to avoid returning TRUE below, and also for performance.
 				break; // Let default proc handle it.
 			switch(nmhdr.code)
 			{
@@ -8872,17 +8871,10 @@ void GuiType::Event(GuiIndexType aControlIndex, UINT aNotifyCode, USHORT aGuiEve
 			// That event (and any others, but especially that one) is ignored because it would launch
 			// the g-label twice: once for lbutton-down and once for up.
 			return;
 
 		case GUI_CONTROL_CUSTOM:
-			if (aEventInfo != 0)
-			{
-				// This is a WM_NOTIFY handler and thus we need to set A_GuiEvent to 'N'. Due to the nature
-				// of WM_NOTIFY messages we cannot use PostMessage because otherwise the NMHDR pointer becomes toast.
-				CustomCtrlWmNotify(aControlIndex, (LPNMHDR) aEventInfo);
-				return;
-			}
 			// Copy the notification code to A_EventInfo.
 			aEventInfo = aNotifyCode;
 			break;
 
 		case GUI_CONTROL_SLIDER:
@@ -9010,28 +9002,28 @@ void GuiType::Event(GuiIndexType aControlIndex, UINT aNotifyCode, USHORT aGuiEve
 	// route AHK_GUI_ACTION messages to the window proc. of the control rather than the parent window, which
 	// would prevent them from being re-posted back to the queue (see "case AHK_GUI_ACTION" in GuiWindowProc()).
 }
 
 
-void GuiType::CustomCtrlWmNotify(GuiIndexType aControlIndex, LPNMHDR aNmHdr)
+int GuiType::CustomCtrlWmNotify(GuiIndexType aControlIndex, LPNMHDR aNmHdr)
 {
 	// See MsgMonitor() in application.cpp for comments, as this method is based on the beforementioned function.
 
 	if (!INTERRUPTIBLE_IN_EMERGENCY)
-		return;
+		return 0;
 
 	GuiControlType& aControl = mControl[aControlIndex];
 	Label& glabel = *aControl.jump_to_label;
 	Line* jumpToLine = glabel.mJumpToLine;
 
 	if (g_nThreads >= g_MaxThreadsTotal)
 		if (g_nThreads >= MAX_THREADS_EMERGENCY
 			|| jumpToLine->mActionType != ACT_EXITAPP && jumpToLine->mActionType != ACT_RELOAD)
-			return;
+			return 0;
 
 	if (g->Priority > 0)
-		return;
+		return 0;
 
 	TCHAR ErrorLevel_saved[ERRORLEVEL_SAVED_SIZE];
 	tcslcpy(ErrorLevel_saved, g_ErrorLevel->Contents(), _countof(ErrorLevel_saved));
 	InitNewThread(0, false, true, jumpToLine->mActionType);
 	DEBUGGER_STACK_PUSH(glabel.mJumpToLine, glabel.mName)
@@ -9042,14 +9034,17 @@ void GuiType::CustomCtrlWmNotify(GuiIndexType aControlIndex, LPNMHDR aNmHdr)
 	g->GuiDefaultWindow = this;
 	g->GuiControlIndex = aControlIndex;
 	g->GuiEvent = 'N';
 	g->EventInfo = (DWORD_PTR) aNmHdr;
 	glabel.Execute();
+	int returnValue = (int)g_ErrorLevel->ToInt64(FALSE);
 
 	DEBUGGER_STACK_POP()
 	Release();
 	ResumeUnderlyingThread(ErrorLevel_saved);
+
+	return returnValue;
 }
 
 
 WORD GuiType::TextToHotkey(LPTSTR aText)
 // Returns a WORD (not a DWORD -- MSDN is wrong about that) compatible with the HKM_SETHOTKEY message:

script.h:

@@ -2511,11 +2511,11 @@ public:
 	static int FindOrCreateFont(LPTSTR aOptions = _T(""), LPTSTR aFontName = _T(""), FontType *aFoundationFont = NULL
 		, COLORREF *aColor = NULL);
 	static int FindFont(FontType &aFont);
 
 	void Event(GuiIndexType aControlIndex, UINT aNotifyCode, USHORT aGuiEvent = GUI_EVENT_NONE, UINT_PTR aEventInfo = 0);
-	void CustomCtrlWmNotify(GuiIndexType aControlIndex, LPNMHDR aNmHdr);
+	int CustomCtrlWmNotify(GuiIndexType aControlIndex, LPNMHDR aNmHdr);
 
 	static WORD TextToHotkey(LPTSTR aText);
 	static LPTSTR HotkeyToText(WORD aHotkey, LPTSTR aBuf);
 	void ControlCheckRadioButton(GuiControlType &aControl, GuiIndexType aControlIndex, WPARAM aCheckType);
 	void ControlSetUpDownOptions(GuiControlType &aControl, GuiControlOptionsType &aOpt);