Quantcast
Whats the proper way to hide a window when you enter into a dialog ? - ESOUI
Thread Tools Display Modes
05/10/14, 08:22 AM   #1
CrazyDutchGuy
 
CrazyDutchGuy's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 89
Whats the proper way to hide a window when you enter into a dialog ?

I am trying to hide a window when i enter any form of dialog. Dialogs, as in menus by pressing esc, inventory, character and so forth.

I tried by setting the following drawlevels of my toplevelwindow to several different values, but it has no effect on entering/exiting dialogs. I am not 100% sure if that is the way to go either.
SetDrawLevel(0)
SetDrawLayer(0)
SetDrawTier(0)

I tried hooking into the following events and hide/show my window if layer 6 is popped/pushed
EVENT_ACTION_LAYER_PUSHED
EVENT_ACTION_LAYER_POPPED

this works. However when i do a reloadui or load into the game it stays hidden, while i set it explicitly to be shown in EVENT_ADD_ON_LOADED. I just can't figure out why it is doing this. I added some debug messages and it should show, but it doesn't.

If i disable the functionality in the EVENT_ACTION_LAYER_PUSHED and EVENT_ACTION_LAYER_POPPED then it just shows correct.

I assume there is an EVENT_ACTION_LAYER_PUSHED done somewhere, but it doesn't register if i add some debug messaging to it, most likely cause not everything is loaded @ reload/start

Anyone an idea how to solve this ?
  Reply With Quote
05/10/14, 09:35 AM   #2
Aicam
Join Date: Apr 2014
Posts: 16
Lua Code:
  1. local fragment = ZO_FadeSceneFragment:New( yourControl )
  2.  
  3. SCENE_MANAGER:GetScene('hud'):AddFragment( fragment )
  4. SCENE_MANAGER:GetScene('hudui'):AddFragment( fragment )

This adds yourControl to the HUD and the UI engine does all the work showing and hiding it when its appropriate. The downsite is you can't remove this show/hide behaviour without a reload of the UI, unless you want to hack into the scene by removing the fragment by force and toggling the scene twice.
Imo triggering an reload when changing something like this is acceptable.
  Reply With Quote
05/10/14, 10:41 AM   #3
Garkin
 
Garkin's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 853
Originally Posted by Aicam View Post
The downsite is you can't remove this show/hide behaviour without a reload of the UI, unless you want to hack into the scene by removing the fragment by force and toggling the scene twice.
Imo triggering an reload when changing something like this is acceptable.
You can remove scene fragment it using:
Lua Code:
  1. yourControl:SetHidden(true)
  2. SCENE_MANAGER:GetScene("hud").fragments[fragment]

EDIT: As of patch 1.1.2 you can use:
Lua Code:
  1. SCENE_MANAGER:GetScene("hud"):RemoveFragment(fragment)
__________________
@Garkin (retired from ESO)
My addons: SkyShards, LoreBooks, Dustman, Map Coordinates, No, thank you!, ... (full list)

Last edited by Garkin : 05/23/14 at 05:34 AM. Reason: updated for patch 1.1.2
  Reply With Quote
05/10/14, 10:49 AM   #4
CrazyDutchGuy
 
CrazyDutchGuy's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 89
I don't see a reason to hack it tbh. It's not a setting that changes a lot. a /reloadui is sufficient.

Thanks for the info.
  Reply With Quote
05/10/14, 06:22 PM   #5
Kentarii
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 42
This works for me to hide my windows when entering menus, dialogues and whatnot..

In init/onload method:
Lua Code:
  1. ZO_PreHookHandler(ZO_GameMenu_InGame, "OnShow", function()
  2.         self:HideIfVisible()
  3.     end)
  4.     ZO_PreHookHandler(ZO_GameMenu_InGame, "OnHide", function()
  5.         self:ShowIfVisible()
  6.     end)
  7.     ZO_PreHookHandler(ZO_InteractWindow, "OnShow", function()
  8.         self:HideIfVisible()
  9.     end)
  10.     ZO_PreHookHandler(ZO_InteractWindow, "OnHide", function()
  11.         self:ShowIfVisible()
  12.     end)
  13.     ZO_PreHookHandler(ZO_KeybindStripControl, "OnShow", function()
  14.         self:HideIfVisible()
  15.     end)
  16.     ZO_PreHookHandler(ZO_KeybindStripControl, "OnHide", function()
  17.         self:ShowIfVisible()
  18.     end)
  19.     ZO_PreHookHandler(ZO_MainMenuCategoryBar, "OnShow", function()
  20.         self:HideIfVisible()
  21.     end)
  22.     ZO_PreHookHandler(ZO_MainMenuCategoryBar, "OnHide", function()
  23.         self:ShowIfVisible()
  24.     end)
(Don't remember anymore in which addon I saw these prehooks handlers first.)

Lua Code:
  1. --- Hide the window if visible and screen state changed to some dialogue/menu interface.
  2. -- @return void
  3. function module:HideIfVisible()
  4.     if self.vars.visible then
  5.         HoWUI_QuestJournal:SetHidden(true)
  6.     end
  7. end
  8.  
  9. --- Show the window if visible and screen state returned to normal.
  10. -- @return void
  11. function module:ShowIfVisible()
  12.     if self.vars.visible then
  13.         HoWUI_QuestJournal:SetHidden(false)
  14.     end
  15. end

HoWUI_QuestJournal is my TopLevelWindow.
self.vars.visible is a SV i use to keep track of if window should be visible or not afterwards.
__________________
My addons: Quest Journal - Research and Mount Timers - Clock - Texture Viewer
Other addons I use: Achievement Tracker, Advanced Filters, Alchemist, AI Research Grid, BatmanStoreFilter, Esohead, Foundry Tactical Combat, Greymind Quick Slot Bar, HarvestMap, Inventory Grid View, Inventory Item Borders, Research Assistant, SkyShards, Sous Chef, TreasureMaps, ZrMM - Modified
  Reply With Quote
05/11/14, 04:41 AM   #6
CrazyDutchGuy
 
CrazyDutchGuy's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 89
Originally Posted by Aicam View Post
Lua Code:
  1. local fragment = ZO_FadeSceneFragment:New( yourControl )
  2.  
  3. SCENE_MANAGER:GetScene('hud'):AddFragment( fragment )
  4. SCENE_MANAGER:GetScene('hudui'):AddFragment( fragment )

This adds yourControl to the HUD and the UI engine does all the work showing and hiding it when its appropriate. The downsite is you can't remove this show/hide behaviour without a reload of the UI, unless you want to hack into the scene by removing the fragment by force and toggling the scene twice.
Imo triggering an reload when changing something like this is acceptable.
This is creating some very weird behavior in the default code. A few things i noticed and getting bug reports from.

Can't drag skills to my action bar anymore cause i tries to call a protected function.
Dialogs aren't properly initialized at moment that EVENT_CHATTER_BEGIN is fired.

  Reply With Quote
05/11/14, 07:19 AM   #7
Aicam
Join Date: Apr 2014
Posts: 16
Well, i never noticed that one. i always used the right click menu to select skills, which has a wastly superior mouse movement economy .
I would consider this a bug in the api. I tried to trigger some onDrag events via scripts and they were all private and since dragging works everywhere else there is something fishy.

Where is this chatter event used and what are the consequences of it.
  Reply With Quote
05/11/14, 08:00 AM   #8
CrazyDutchGuy
 
CrazyDutchGuy's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 89
The problem with the EVENT_CHATTER_BEGIN is that when it fires - and it allways fires when starting a dialog with a NPC - that at the moment of firing the dialog is being build up.

If you use an addon that uses information that exists out of that dialog it could happen that the dialog is not fully finished building, when extracting information.

Specific with my addon hooking into the scenemanager, it caused issues in the addon Dialog Tweaks. Which normally should not happen, cause i am not doing anything related with the EVENT_CHATTER_BEGIN event. But the case was that Dialog Tweaks asks if a certain option is visible in the dialog, and if so, does something with it. What i could figure out with some debug statements was that the hidden property was not set at the moment the addon inquired, but when the dialog was fully loaded, it was.

I am pretty sure there are more minor conflicts going on, but these are the one i could find out, or actually people pointed me to it. Someone mentioned also that it caused issues with Fast Travel addon.

All this, just because i added something to the scenemanager.
  Reply With Quote
05/11/14, 08:45 AM   #9
Roupine
Join Date: May 2014
Posts: 18
I've been using EVENT_ACTION_LAYER_POP/PUSH, but the fact that they trigger on menus and dialogs is only a coincidence since Action Layers are all about Keybinding contexts. That's more hack-ish than I'm comfortable with.

The best hack I've found is to set the Control's parent to the Compass if I want it to hide when menus open, since that's what the Compass does (and the Control inherits that behavior).
  Reply With Quote
05/11/14, 09:12 AM   #10
Aicam
Join Date: Apr 2014
Posts: 16
Ok, I found the source of all the problems, i could conform.

Lua Code:
  1. local fragment = ZO_SimpleSceneFragment:New( yourControl )
  2.  
  3. ...
Apparently the fade animation messes up, the timeline in SCENE_MANAGER. That this can influence
the dialog window is quite intuitive, and the reason i found this solution, why this is breaking the drag event in the skill menu is certainly another matter .
Anyway this should fix all issues and a 0.2sec fade animation is hardly impoertant to most people .

edit:
I still can't reproduce any problems with the fast travel system, using either fragment classes, i jumped around for about 30min between wayshrine and i still have as much money as before.

Last edited by Aicam : 05/11/14 at 10:35 AM.
  Reply With Quote
05/11/14, 10:42 AM   #11
CrazyDutchGuy
 
CrazyDutchGuy's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 89
The bug with travelling as posted on my addon
Somehow, this mod is causing problems with Fast Travel and the costs therein. I'm sure you're aware that if you go to a WayShrine and Travel to another shrine, there is not cost. This, as opposed to traveling to another shrine, when you're in the field.

Since 2.4, i've run into a few instances, where this form of travel, from shrine to shrine, is now costing gold. Actually, it's not even traveling from shrine to shrine. Even though i'm at a shrine, and i *use* the shrine to travel, it actually performs a teleport instead, hence the cost.

I've narrowed it down to this mod @ vers 2.4. Rolling back to 2.3 returns everything to normal, which is expected, as the bug has only been on my system for the last day or so.

This always happens when traveling *from* Davon's Watch in Stonefalls, and sometimes in other towns that have a shrine inside the town, Ebonheart and Kragenmoor for example.
I assume this is just again another timing issue. Think the addon was Fast Travel or something. Did not really look into it, cause the problem was kinda indentified by the other addons


Originally Posted by Aicam View Post
Ok, I found the source of all the problems, i could conform.

Lua Code:
  1. local fragment = ZO_SimpleSceneFragment:New( yourControl )
  2.  
  3. ...
Apparently the fade animation messes up, the timeline in SCENE_MANAGER. That this can influence
the dialog window is quite intuitive, and the reason i found this solution, why this is breaking the drag event in the skill menu is certainly another matter .
Anyway this should fix all issues and a 0.2sec fade animation is hardly impoertant to most people .

edit:
I still can't reproduce any problems with the fast travel system, using either fragment classes, i jumped around for about 30min between wayshrine and i still have as much money as before.
  Reply With Quote
05/12/14, 01:58 AM   #12
LoPony
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 10
Originally Posted by Aicam View Post
Lua Code:
  1. local fragment = ZO_FadeSceneFragment:New( yourControl )
  2.  
  3. SCENE_MANAGER:GetScene('hud'):AddFragment( fragment )
  4. SCENE_MANAGER:GetScene('hudui'):AddFragment( fragment )

This adds yourControl to the HUD and the UI engine does all the work showing and hiding it when its appropriate. The downsite is you can't remove this show/hide behaviour without a reload of the UI, unless you want to hack into the scene by removing the fragment by force and toggling the scene twice.
Imo triggering an reload when changing something like this is acceptable.
Any possibility to have some control about this?
Currently it hides the UI if you use siege weapons, I would like to remove that behavior.

edit: well I just found it. This does the job
Code:
SCENE_MANAGER.scenes.siegeBar:RegisterCallback( 'StateChange', function( oldState, newState ) 
  if( newState == 'showing' ) then
    myControl:SetHidden( false )
  end
end )

Last edited by LoPony : 05/12/14 at 02:13 AM.
  Reply With Quote
05/12/14, 07:55 AM   #13
Garkin
 
Garkin's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 853
Originally Posted by LoPony View Post
Any possibility to have some control about this?
Currently it hides the UI if you use siege weapons, I would like to remove that behavior.

edit: well I just found it. This does the job
Code:
SCENE_MANAGER.scenes.siegeBar:RegisterCallback( 'StateChange', function( oldState, newState ) 
  if( newState == 'showing' ) then
    myControl:SetHidden( false )
  end
end )
I think that the proper way is to add your fragment to siege scene:
Lua Code:
  1. SCENE_MANAGER:GetScene("siegeBar"):AddFragment( fragment )
__________________
@Garkin (retired from ESO)
My addons: SkyShards, LoreBooks, Dustman, Map Coordinates, No, thank you!, ... (full list)
  Reply With Quote

ESOUI » Developer Discussions » General Authoring Discussion » Whats the proper way to hide a window when you enter into a dialog ?

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off