Kodi Community Forum

Full Version: Some questions regarding windows handling
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
1. <ononluad> for a window - is this called on ActivateWindow() for another window? What if the window activated is a dialog?
2. How to close a custom dialog, returning back to calling window? Are there some default buttons for a custom dialog with default actions?
3. I am calling ActivateWindow() from a custom dialog. Should I somehow cleanup current custom/normal dialog before calling ActivateWindow()?
1. <onunload> is called when the window closes, so it doesn't happen for MyVideoNav when DialogVideoInfo is called because MyVideoNav is still open behind the dialog. However, if you have an <onunload> in DialogVideoInfo it will happen when you go back to MyVideoNav (because the dialog closes).

2. <onclick>Close</onclick> should work fine (or whatever other tag, like onleft or whatever). Otherwise you can use Dialog.Close(ID)
See these wiki entries for commands you can use in <onclick> <onleft> etc. commands
Action_IDs (wiki)
List_of_built-in_functions (wiki)

3. You will likely have to close the custom dialog before calling another window etc.
e.g.
Code:
<control type="button">
    <onclick>Close</onclick>
    <onclick>ActivateWindow(foobar)</onclick>
</control>
So, there is always a full stack of open windows which can be navigated back with returns from the current dialog? And if I have different background for different windows, all they are kept in the memory? Is there some guide/best practices regarding memory management in skins?

Does closing any of the visited explicitly windows break the chain or just remove one link?

What about querying a window which has not been opened yet with Window([window]).Property(key)? Does it instantiate the window in the background, not displaying it, or just constructs the fetched value?
For memory management it is my understanding that using the visible tag for the backgrounds will help with that... The window(id). Property (key) in most cases is only available after you setproperty (key,value,I'd) somewhere in the skin.

Not sure I follow with the rest of what your asking
I mean what about a situation when you call Window(weather).Property(some_prop) without opening weather window beforehand. Is the property populated/instantiated magically in the background?
(2017-03-27, 19:10)baza_dwa Wrote: [ -> ]I mean what about a situation when you call Window(weather).Property(some_prop) without opening weather window beforehand. Is the property populated/instantiated magically in the background?

Kodi handles memory management. No need to do anything like that in the skin. Yes you can access other window properties from outside the window (you just can't access skin strings or window properties inside itemlayout/focusedlayout, but that's a whole other story).

I'm not sure with Weather. I remember that previously you had to go into the window first, but I don't think that happens anymore and the properties are just filled as soon as the weather is fetched regardless of where you are (not 100% on this, but pretty sure). You can always access Home window properties where ever you are.

Whenever you use ActivateWindow, kodi will remember the previous window it came from. When going back it will follow that breadcrumb trail. All the "return" in an ActivateWindow does is tell kodi that you want to go back to the previous window when you reach that library node rather than going back through the whole library to the base window.

For instance,
Code:
ActivateWindow(Videos,videodb://movies/genres/,return)
Will take you to movie genres, where you can click on categories like Action and then press back to return to genres. However, because of the return parameter, when you press back from the genres page, it will go back to the previous window rather than down one level to videodb://movies -- If you didn't specify return, you would go back to the parent videodb://movies folder and then to its parent videodb:// folder before returning to the previous window.

If you want to take the current window OUT of the breadcrumb trail then use ReplaceWindow instead. This tells kodi that instead of adding the next window to the trail, replace the current one in the trail with the new one.

You can't explicitly close a window in the breadcrumb trail because only one window is open at a time. However, you can have a stack of dialog windows and explicitly close one with Dialog.Close -- I think in that case, going back just returns to the next one in the stack.
Just one more question - how do I close the current non-dialog window, going back? I cannot find any action on the List of Built In Functions... In keymap there are functions like Back or ContextMenu, but they are not on the list.
I linked you a list of the Action IDs that are used in keymaps before (back and contextmenu are in there)
Action_IDs (wiki)

I'm not sure exactly what you mean, but you can use keymap actions as <onfoo> commands (e.g. onclick, onleft, onback etc.)

Code:
<onclick>Back</onclick>
Acts like you pressed back on the remote (or backspace on keyboard) -- so this will follow <onback> if specified for that control, or otherwise go up to the parent folder or to the previous window if on the base node of the library (or "return" was specified in the previous ActivateWindow command and you are at the respective node).


Code:
<onclick>Close</onclick>
Acts like Back as well, I'm not sure if its an alias or has a slightly different function (maybe in regards to dialogs).



Code:
<onclick>PreviousMenu</onclick>
Goes directly back to the previous window


Code:
<onclick>ParentDir</onclick>
If you only want to go up a node (like clicking the ".." in a folder).
(2017-03-29, 07:08)jurialmunkey Wrote: [ -> ]
Code:
<onclick>Close</onclick>
Acts like Back as well, I'm not sure if its an alias or has a slightly different function (maybe in regards to dialogs).

yup 'close' is an alias for 'back'
'parentdir' is an alias for 'back' as well.

both 'close' and 'parentdir' are deprecated, so it's best to only use 'back'.
(2017-03-29, 18:34)ronie Wrote: [ -> ]
(2017-03-29, 07:08)jurialmunkey Wrote: [ -> ]
Code:
<onclick>Close</onclick>
Acts like Back as well, I'm not sure if its an alias or has a slightly different function (maybe in regards to dialogs).

yup 'close' is an alias for 'back'
'parentdir' is an alias for 'back' as well.

both 'close' and 'parentdir' are deprecated, so it's best to only use 'back'.

Good to know. Looking at the button translator I'm guessing "parentfolder" does what I assumed "parentdir" did? If so, its not on the wiki in either Action IDs or Built-in Functions.