I finally had a need to use the "OnActivateWindow" event in the MacroLanguage, but using it seems to always crash KM. The requirement that I have is to run a macro when a window is closed and a remaining window gets focus. I need to sync the display of a button with the value of a pref. That pref may have been changed in the window just closed.

I have this test code. I originally wrote it to verify the order of events back in 2012. I just added "OnActivateWindow" today. I have tried it in KM 74 beta 4 and KM 1.6 beta 2.6. It crashes both.

EventOrder.kmm

#  K-Meleon Macros (http://kmeleon.sourceforge.net/wiki/index.php?id=MacroLanguage2)
#
# ---------- EventOrder.kmm
# ---------- code testing for order of events
# ---------- Alert user to every event when it happens
#
# Dependencies        : main.kmm
# Resources           : -  
# Preferences         : -
# Author              : JamesD
# Version             : 2.1 2014_07_10
# -------------------------------------------------- 

_EventOrder_OnCloseTab {
alert("OnCloseTab", "Event Action", INFO);
}
_EventOrder_OnOpenTab {
alert("OnOpenTab", "Event Action", INFO);
} 
_EventOrder_OnLoad {
alert("OnLoad", "Event Action", INFO);
$_EventOrder_loadcount = $_EventOrder_loadcount + 1;
} 
_EventOrder_OnStartup {
alert("OnStartup", "Event Action", INFO);
}
_EventOrder_OnInit {
alert("OnInit", "Event Action", INFO);
$_EventOrder_loadcount = 0 ;
}
_EventOrder_OnSetup {
alert("OnSetup", "Event Action", INFO);
}
_EventOrder_OnWMAppExit {
alert("OnWMAppExit", "Event Action", INFO);
}
_EventOrder_OnCloseWindow {
alert("OnCloseWindow", "Event Action", INFO);
}
_EventOrder_OnOpenWindow {
alert("OnOpenWindow", "Event Action", INFO);
}
_EventOrder_OnActivateWindow {
if ($_EventOrder_loadcount > 0){
	statusbar ("Event Action ==>>  OnActivateWindow"); 
	## cannot have alert-msgbox gets focus = endless loop
	## kills KM if no window loaded
}
}

$OnCloseTab=$OnCloseTab."_EventOrder_OnCloseTab;";
$OnOpenTab=$OnOpenTab."_EventOrder_OnOpenTab;"; 
$OnLoad=$OnLoad."_EventOrder_OnLoad;"; 
$OnStartup=$OnStartup."_EventOrder_OnStartup;";
$OnInit=$OnInit."_EventOrder_OnInit;";
$OnSetup=$OnSetup."_EventOrder_OnSetup;";
$OnWMAppExit=$OnWMAppExit."_EventOrder_OnWMAppExit;";
$OnCloseWindow=$OnCloseWindow."_EventOrder_OnCloseWindow;";
$OnOpenWindow=$OnOpenWindow."_EventOrder_OnOpenWindow;";
$OnActivateWindow=$OnActivateWindow."_EventOrder_OnActivateWindow;";

$macroModules=$macroModules."EventOrder;";

Works fine here.

Did you open and then close a second window?

The only problem I see is that the status bar may not be properly initialized, and I can fix that. But if you do something else, it should be fine.

OK, I will try. I need to sync a button's status with a pref. I will report results.

I suspect that I have an imperfect understanding of OnActivateWindow. The OnActivateWindow event happens when a window get focus. At least I think that is correct.

So if I have a window open the event happened. Now if I open a second window, then the second window get focus and the event happens again. If I close the second window, does not the first window then get focus? Does the event happen for focus returning to the first window?

The requirement is that if I clicked on an button which toggled the value of a pref while in the second window, I need the button in the first window to reflect that change. Is this possible?

It is not working in my current code.

I found a better way to sync the button. OnCloseTab works in the window to which focus is returning.

Dorian, there is not any need for a change.

OnActivateWindow is send whenever a windows become active. So it should be send when you close a window, and another kmeleon window is activated.

Before the latest update, OnCloseTab wasn't send when closing a window.

The OnActivateWindow event is not happening when I have two windows and use FILE - PREVIOUS WINDOW to change between the two. This is using KM Beta 4 with update 1.

The test was as follows:
Open KM
Open a second window
In the second window, click on a button which changes the color and a pref
Use file - previous window to return to first window
The button remains the original color.
Move the mouse over the button and it changes to window two's color

There is code to sync the button to the pref called like this:

$OnActivateWindow=$OnActivateWindow."_JSP_flipsync;";

Is changing windows within KM considered to be changing focus?


Note that if I go to a window not part of KM, then the button syncs to the pref. Therefore I know that _JSP_flipsync works.



Edited 1 time(s). Last edit at 07/14/2014 11:37PM by JamesD.

The event is sent even between km windows, I'm quite sure of it.

But I have another issue here, if you change a toolbar button, it should do the change for all windows not just the current one.

Maybe I did not make the toolbar correctly. I just know it is there but does not change (sync).

This is the code: https://dl.dropboxusercontent.com/u/1522294/JSPoliciesList.7z

Will be fixed in next update

For not making more threads.

I've gathered together all files involved in History fix, published by JamesD.

Dorian, you can get this file and use it in the next update.

Well, it contains now zero-sized places.kmm which normally should be removed at all. But I've made this archive for current users in order to fix issue in simple 'unpack and forget' way. :cool:



Edited 1 time(s). Last edit at 07/16/2014 06:58PM by rodocop.

Dorian

OnActivateWindow ...
Thanks. It was driving me up a wall that I could not fix it myself.

History stuff ...
To keep or delete places.kmm is up to you. Deleting might not fit everyone's idea of the direction in which we should go. Deleting was just me being me.

Deleting places.kmm removes the unneeded menu entry which is also non-localizable (as I understand, menu item was not determined as variable - but I may be wrong).

So to delete is a good idea for me!

Quote
rodocop
Deleting places.kmm removes the unneeded menu entry which is also non-localizable (as I understand, menu item was not determined as variable - but I may be wrong).

I did not notice the localization problem, but TOOLS did not seem the correct place for History.

Quote
JamesD
but TOOLS did not seem the correct place for History.

And this is one more reason to delete! So you are right!