How to know if Ionic split pane is opened or closed? - ionic-framework

I'm trying to adjust some CSS properties depending on the state of the split pane, I mean, if it is opened or closed. I can detect when its state changes using ionChange event on the view, but I can't know if it was opened or closed. Is there a way to do this?
Split Pane documentation: https://ionicframework.com/docs/api/components/split-pane/SplitPane/

I was looking for the same behavior and found this. Here's an example:
<ion-split-pane (ionChange)="onSplitPaneChange($event)">
...
</ion-split-pane>
And in your component:
onSplitPaneChange(e) {
if (e._visible) {
// desktop
} else {
// mobile
}
}
This was tested for Ionic 3.
According to Redwolf, on Ionic 4 you'll have to read e.detail.visible instead of e._visible (I didn't try it myself yet - comment if you did). The rest may remain and works the same way though.

Related

How do you automatically focus on an inputfield when opening/activating the UI in Unity3d?

I am making a game where you must open or activate the UI with the space bar. Now, this works perfectly fine, but it is pretty annoying that every time you open the UI you must click on the inputfield to write in it. Is there any way around this? So is there a way to open or activate the UI without having to click on the field to be able to write in it?
I looked for YouTube videos and tried to find similar problems in other forums, but wasn't able to find a script, nor was I able to find some Unity settings to do so.
You could use e.g.
private class SelectOnEnable : MonoBehaviour
{
private void OnEnable()
{
EventSystem.current.SetSelectedGameObject(null);
EventSystem.current.SetSelectedGameObject(gameObject);
}
}
and attach it to whatever object that should become the selected one everytime it is enabled. See EventSystem.SetSelectedGameObject
Can't test it right now but it might still require the User to hit Enter in order to also actually set the Input field into edit mode. The upper line only sets it as selected UI element (similar to using TAB in a browser).
Otherwise I think you would go through
yourInputField.DeactivateInputField()
yourInputField.ActivateInputField();
to directly set it active. See InputField.ActivateInputField. Might have to do both in combination - again can't test right now ;)
Thank you very much, derHugo! Everything works like a charm now! You saved me a lot of time. Referring to your last comment, I used both of them, and it seems to work very well for me. Here is the code I used:
`private void OnEnable()
{
EventSystem.current.SetSelectedGameObject(gameObject);
GameManager.GetComponent().inputFieldInMainUi.ActivateInputField();
EventSystem.current.SetSelectedGameObject(null);
GameManager.GetComponent<InputFieldComparision>().inputFieldInMainUi.DeactivateInputField();
}`

My question is about Ability for an author to reorder each tab within the component dialog in aem

enter image description here
I want to know how to provide the numbering for each tab, so that author can provide the number as per their requirement.
This is the strangest requirement I ever heard of. You can sure do that, but it didn't make much sense of doing it system wide as one author can feel the dialog one way, other in completely different. The only reasonable solution is to use javascript to reorder the tabs in the way an author want and than save the settings for this specific component in his user profile. You can start implementing it by creating a clientlib with the category cq.authoring.dialog. In your JS you have to listen to specific dialog loading event as shown below. I think this should be enough and it's a good starting point.
// necessary as no granite or coral ui event is triggered, when the dialog is opened
// in a fullscreen mode the dialog is opened under specific url for serving devices with low screen resolution
if (location.href.match(/mnt\/override/)) {
$(window).on('load', function(e) {
setTimeout(doSomething, 100);
});
} else {
$(document).on('dialog-ready', function(e) {
Coral.commons.ready(function(){
setTimeout(doSomething, 100);
});
});
}
You can use granite:rel to define specific identifiers in the dialog definition and use save them later in the user settings. You can define drag & drop events using the tab selector [role="tab"].
This is not trivially possible. Decide upfront about the order when building the component, provide meaningful labels and go with that. Touch UI does not provide the feature you need.

How to detect if side menu is open/closed in ionic 2?

I am using cordova-google-maps plugin with my ionic 2 app, and I want to show the menu (sidenav) on that page. Problem is for the sidenav to receive events properly I need to call map.setClickable( false ) while opening the sidenav and set it back to true when the user closes the sidenav. It seems there is an event for checking while the menu is being opened with opening, but I don't know how to track when the user closes the menu.
For using ionDrag, ionOpen, ionClose in Ionic2 you must add it on the menu itself
for example modify menu in your app.html file by
<ion-menu [content]="content" (ionOpen)="menuOpened()" (ionClose)="menuClosed()">
After I use "Events" see doc here: http://ionicframework.com/docs/v2/api/util/Events/
For detect in my page if the menu was close or open.
Example in my app.ts
menuClosed() {
this.events.publish('menu:closed', '');
}
menuOpened() {
this.events.publish('menu:opened', '');
}
And in my other page
events.subscribe('menu:opened', () => {
// your action here
});
events.subscribe('menu:closed', () => {
// your action here
});
I hope this help
It seems new events have been added to the menu component which solves this problem. I am also using the google maps plugin and it works fine
http://ionicframework.com/docs/v2/api/components/menu/Menu/
ionDrag
When the menu is being dragged open.
ionOpen
When the menu has been opened.
ionClose
When the menu has been closed.
Using these output events, in your handlers you can keep a flag for the menu if its open or not :)

Ionic2: Reload the ion content when back button is pressed

How do I reload the content sitting under <ion-content> tag when back button is pressed?
The answer which is there is correct, however, it is outdated. Here is the updated answer.
Link to the Life Cycle just scroll down and you should see it.
Example:
ionViewWillEnter() {
console.log('Runs when the page is about to enter and become the active page.');
}
Just use a View Lifecycle Hook in the view you are going back you have to use for example:
onPageWillEnter() {
// You can execute what you want here and it will be executed right before you enter the view
}
Or you use a lifecycle hook on the page you are leaving then just replace onPageWillEnter() with onPageWillLeave()
With ionic beta 8 the lifecylcle events changed their names. Check out the official ionic blog for the full list of the lifecycle events.

Addon SDK way to make a dialog

What is the proper way to use the SDK to make a dialog (which is not anchored to the add-on bar, etc. but shows centered on screen)? It doesn't seem like there is any API for this important capability. I do see windows/utils has open but I have two problems with that:
The dialog opening seems to require "chrome" privs to get it to be centered on the screen (and I'd be expectant of add-on reviewers complaining of chrome privs, and even if not, I'd like to try to stick to the SDK way).
While I can get the DOM window reference of the new window/utils' open() dialog, I'm not sure how to attach a content script so I can respond to user interaction in a way that prompts (and can respond to) privileged behavior ala postMessage or port.emit (without again, directly working with chrome privs).
Ok, this answer should have been pretty obvious for anyone with a little experience with the SDK. I realized I can just use a panel. In my defense, the name "panel" is not as clear as "dialog" in conjuring up this idea, and I am so used to using panels with widgets, that it hadn't occurred to me that I could use it independently!
Edit
Unfortunately, as per Bug 595040, these dialogs are not persistent, meaning if the panel loses focus, the "dialog" is gone... So panel looks like it is not a suitable candidate after all... :(
Edit 2
I've since moved on and have gotten things working mostly to my satisfaction with sdk/window/utils and openDialog on whose returned window I add a load listener and then call tabs.activeTab.on('ready', and then set tabs.activeTab.url to my add-on local HTML file so the ready event will get a tab to which I can attach a worker. There is still the problem with chrome privs I suppose, but at least the main communications are using SDK processes.
Update to Edit 2:
Code sample provided by request:
var data = require('sdk/self').data,
tabs = require('sdk/tabs');
var win = require('sdk/window/utils').openDialog({
// No "url" supplied here in this case as we add it below (in order to have a ready listener in place before load which can give us access to the tab worker)
// For more, see https://developer.mozilla.org/en-US/docs/Web/API/window.open#Position_and_size_features
features: Object.keys({
chrome: true, // Needed for centerscreen per docs
centerscreen: true, // Doesn't seem to be working for some reason (even though it does work when calling via XPCOM)
resizable: true,
scrollbars: true
}).join() + ',width=850,height=650',
name: "My window name"
// parent:
// args:
});
win.addEventListener('load', function () {
tabs.activeTab.on('ready', function (tab) {
var worker = tab.attach({
contentScriptFile: ....
// ...
});
// Use worker.port.on, worker.port.emit, etc...
});
tabs.activeTab.url = data.url('myHTMLFile.html');
});
if the panel loses focus, the "dialog" is gone...
It doesn't get destroyed, just hides, right? If so, depending on why it's getting hidden, you can just call show() on it again.
You'd want to make sure it's not being hidden for a good reason before calling show again. If there's a specific situation in which it's losing focus where you don't want it to, create a listener for that situation, then call if (!panel.isShown) panel.show();
For example, if it's losing focus because a user clicks outside the box, then that's probably the expected behaviour and nothing should be done. If it's losing focus when the browser/tab loses focus, just register a tab.on('activate', aboveFunction)
Simply adding ",screenX=0,screenY=0" (or any values, the zeroes seem to be meaningless) to the features screen seems to fix centerscreen.