My issue stems from wishing to have a mobile phone rendered in the page, which mimics that of an actual phone. I would like to use components from Material UI such as AppBar and Dialog, however they do not stay confined to the container of the phone, and instead still show in the entire browser window.
When I use a Dialog Component however, it's still relative to the actual browser viewport, and not that of the "phone", such as the following:
I would like it to do what is seen in the picture below, without using an IFrame.
Is there a way I can set an anchor for the components - or at least force them to treat a specific element as their boundary? Thanks.
For those wondering if this is resolved, the solution was to roll my own Dialog and Backdrop Components with Paper, and Box components.
A ref was passed into a Box component which surrounds the entire "Phone App", and it's current Element is passed into a Mui Portal's container property.
This allows for the container of the Custom "Dialog" to be the container I wished to have things bounded by.
Related
I was having an accessibility issue when using Material-UI with React. Specifically when placing a Menu on a Drawer. Essentially the normal behaviour of a Menu is to highlight the top MenuItem. This behaviour is different if that menu is placed on a Material UI Drawer.
I have recreated the problem here using just the example Material-UI Menu and Drawer:
https://codesandbox.io/s/material-ui-menu-and-drawer-accessibility-issues-xjj3h?file=/src/App.js
The following images show the difference between the two menus when opened. I am using the chromevox extension while testing:
A normal menu when using chromevox to show accessability:
A menu when it is placed on a material UI drawer:
Would anyone be able to point out if this is an error in my code or if perhaps there are any workarounds? Was going to raise this as a new github issue but felt it was worth asking the question here first. :)
By default, the drawer enforces (so long as it is open) that focus stays within itself. So when the menu opens and grabs focus, the drawer notices that it lost focus and it grabs it back.
There are two options for fixing this:
You can turn off this drawer behavior by specifying the disableEnforceFocus prop (example here).
You can specify the disablePortal prop on the menu (example here). This will cause the menu to be a descendant of the drawer in the DOM (by default the menu uses portals and is added as a child of the <body> element), so the drawer will not try to "take back" the focus, because when focus is in the menu it will still be within the drawer.
I would recommend option 2 since the drawer's focus enforcement is generally a good thing from an accessibility standpoint.
So do I need to remove the from the Dom ? If so how do I do this ? I have an control on an SPFX Extension within SharePoint. The panel works fine and the props and the state is ok. when I click close the panel closes, but it doesn't trash the object - this means that the screen in the background remains grey.
I have used the react developer tools and I have been through all the states and I cannot find one that 'removes the component from the DOM' as such. I need the object completely going.
<Panel
headerText='Case Approval'
type={PanelType.medium}
onRenderFooterContent={this._onRenderFooterContent}
isOpen={this.state.showPanel}
isHiddenOnDismiss={this.state.hidden}
onDismiss={this._hidePanel}
focusTrapZoneProps={{}}
hasCloseButton = {this.state.hasCloseButton}>
My problem is that I didn't find any way to properly add an icon near a TextComponent, inside a TextModeLayout, to mask/unmask a password.
It's a layout problem only, because the code of the ActionListener to mask/unmask the password works correctly at least in the Simulator (it's taken from Codename One - Mask and Unmask Password Field on iOS).
On iPhone skin, the InputComponents labels and text fields are not aligned correctly:
On Android skin, the text is not aligned correctly if it doesn't valide:
About my code, instead of adding the InputComponent (of the password) directly to the TextModeLayout container, I enclosed the InputComponent and the Button inside a BorderLayout, and then I added the BorderLayout container to the TextModeLayout container.
When you do that the text mode layout stops working for that component as it's unaware of the layout in the hierarchy. The hierarchy in the border layout is the responsibility of that layout.
The solution is to extend the TextComponent and add that functionality to Codename One. As a workaround we might be able to rely on the behavior of the current component since the field is already in a border layout component. So something like this might work:
TextField tf = myTextComponent.getField();
Container b = tf.getParent();
b.add(EAST, unmask);
Some time ago I noticed that nested scrollable containers behave nice - for example several containers scrollable in their X-axis nested in a container that is scrollable in its Y-axis - and decided to take advantage of this by creating a custum composite swich component based on that and snapToGrid.
However this never worked out nicely since snapToGrid had its problems.
When I talk about well-behaviour of nested scrollable components I mean you can tap on a nested scrollable component and it will just work well being able to scroll either the component itself or its also scrollable parent in the other axis.
What would I need to do in a custom scrollable component to achieve the same well-behaviour like it works with nested containers?
What I'd require of such a component - for example a switch - was beeing able to switch it horizontally while, once it notices that horizontal dragging threshold is reached, and not to affect its parent containers vertical scrolling then. The other case where, after a certain threshold of vertival scrolling in the parent component, it locks to vertically scrolling the parent container should already work, right?
By the way - with the out-of-the-box CN1 OnOffSwitch this does not work. When they are placed in containers nested in a container with BoxLayout.Y the this way represented list cannot be scrolled when tapping one of the OnOffSwitches and dragging vertically.
Events in Codename One are delivered from the system in the following order:
The parent Form - e.g. you can override the pointer* callbacks
Form listeners - e.g. appPointer*Listener on Form
Builtin scroll if you are scrolling
Focused component
I'm assuming you used focus to grab events which essentially blocks child components from grabbing the events.
If you did such a thing you need to deliver the events to the child yourself using the pointer callbacks on the given component. You can find the component at a given x/y coordinate using getComponentAt(x, y).
I'm trying to create Custom Form configuration with scrollable TitleArea. The Form (black) has a BoxLayout.Y_AXIS Layout in BorderLayout.CENTER (blue). StatusBar (green) stays in BorderLayout.NORTH (green), when rest of the TitleArea (cyan) is in the first position in BoxLayout.
removeComponentFromForm function is unavailable for using in extended class. How can I remove components from Form to removing titleArea from BorderLayout.NORTH?
Why use the title area at all? Why not just add a component to the top of the box layout Y and style it as a Title that way you can scroll it out?
You can also use the new Toolbar API that includes many abilities to fade out the title as you scroll etc. See:
http://www.codenameone.com/blog/toolbar.html
http://www.codenameone.com/blog/cats-in-toolbars.html