Any update on timing for a fix on this one?
Unfortunately, no. We are still considering this a low priority on our end for now. But I can definitely let you know when we get to it!
We have been testing a touch screen application and the current size of the on demand button is borderline unusable on our screens especially if the calibration is slightly off. With the inability to change the button size as well we wanted to throw a custom button to open and close the docks but the loss of modal really throws a wrench in the flow of our application. We could add a close button on the dock but I’d like to avoid it. Could we get the button size or this modal thing potentially moved up in the priority list?
There is active work on designing UI for Docked View Handle customization but it’s in the Design phase, so I would not expect it before 8.0.4 at the earliest. 8.0.5 is much more likely.
Since the Modal issue requires less effort than the new UI, the modal issue is likely going to be fixed before the new UI process is complete.
Bumping the priority is unlikely as there are a number of factors which go into determining the priority of each issue, but there was a note added to the ticket that the issue is still active and receives regular inquiries.
Sounds good. Thanks!
Alternatively, if you could pass modal=True into system.perspective.openDock that could help with using the buttons. Not sure if that is an easier solution to this bug or not. Having the ability to make the handles bigger and look how we want (to replace a custom button) would be ideal though.
Any update on this - either from a different handle or at least having the dock open in modal when fired from a button when its configured that way?
I remember seeing end-stage design work, but we have not begun to implement the new UI for creating Docked Views which includes customization of the handle dimensions as well as a “modal” setting which allows for background dismissal.
As far as opening a Docked View in modal from a button click - that’s not something we’re looking into doing. The configuration of the Docked View is done in the Page Configuration (including the modal setting); opening/closing/toggling the Docked View gets no say in the configuration of the Docked View.
This is fine, but I would expect that when I open a docked view from a button action it would obey the configuration from the Page Configuration, which I have set to modal. It does not do that and opens the dock without it being modal.
On a side note, is there anyway to reference what the dock that is set up for a page from the page configuration? Right now if I were to add a button on every view or page in my session I have to configure which dock to open on that action. It kind of renders the dock setup in the Page Configuration partly useless because I still have to put in the correct DockID on every action. If it was able to reference the Page Configuration it would be far easier to implement on every page.
This is the description of the bug which was opened a long while ago, and that bug has not been resolved as of yet. This thread should be updated when that happens.
Unfortunately, no, because when you’re working with a component, you are within a View. Views have absolutely no idea they will be used as a “Page”, because there is every possibility that they will not be. Essentially, the View you are within knows ONLY about View properties, which include its children and any of their properties.
Not entirely true - assuming these Views will all be opening the same Docked View; you could easily make a small View which contained ONLY the button you’re looking to use for the action, and then each View would utilize an Embedded View, which supplies a path to the View which contains your button. Now you’ve configured the Action in one View only one time, and you have Embedded Views in each of your Views which point at that View.
Any update on this? I know it may not be the highest priority, but its been a while for what seems like a pretty small fix.
I’ll bring this ticket up next development cycle, but priority is the driving force which determines when we take a ticket on - not ease of effort.
I know there has been a few bugs/needs/wants in this thread, but Is the open bug in regards to the ability to have a modal docked view?
And if so, is there any workaround that you can think of?
The original issue was regarding Docked Views which should open as a “modal”, but which fail to do so when opened/toggled as part of an Event. It looks to me that the modal setting is working correctly as long as you use the Docked View’s handle; it’s only Docked View Events or scripts which use
toggleDock() which have an issue.
So I guess the workaround is to only use the handles of the Docked View.
Update: Actually, it looks like if the Docked View is not the default 150px size we supply then the modal appearance is not working. I’ll update the ticket with this new info. So the NEW workaround is to only use the handles and ONLY use the default size.
Any update on this one? I just tried it in 8.1 and it still looks like its persisting.
We will update this post when a fix is in place.
Just thought I’d flag this so I get updates.
Any update on this? Still not working for 8.1. Also just trying to bring it to attention again.
What version of
8.1? Our internal ticketing system shows that this issue was fixed as part of 8.1.5.
8.1.4 I was waiting to update but wasnt sure if this was fixed. If it’s been resolved in 8.1.5 then I will upgrade thank you