I am trying to create a nested side menu for a CN1 application, similar to the one in the screenshot.
For the nested sidemenu to work, I image it has to stay open when the user presses a command of a dropdown list , so that he/ she can choose an option.
But the CN1 sidemenu appears to close every time and I couldn't find a workaround.
One approach I was trying was to add an action event to the "hamburger menu ", but this doesn't seem to work.
Button sideBtn = (Button)((BorderLayout)bar.getLayout()).getEast();
sideBtn.addActionListener(new ActionListener(){
#Override
public void actionPerformed(ActionEvent evt) {
Toolbar.setPermanentSideMenu(true);
};
Neither does adding Toolbar.setPermanentSideMenu(true) to any other button's action event.
Anther approach I have in mind is to add hidden buttons to the sidemenu and repaint the toolbar when the button is clicked, but this still does not keep the sidemenu open and seems to be not very direct.
Is there anything more straightforward? What would be the best approach?
Thanks in advance for any kind response.
The setPermanentSideMenu method is designed for tablets and not for what you are trying to do. Toggling it after the init(Object) method was invoked doesn't make sense and might break your app.
You didn't list how you added the button to the side menu but adding it using addComponentToSideMenu(Component) should work (notice I didn't use the version that accepts a Command).
Related
How can I prevent the showing of the Next or Done buttons of the Android VKB in a Codename One app?
Currently, for my app, they are a mess: the next button of the VKB doesn't focus the next field, but the previous. After tons of trials, I didn't find a way to make them working correctly (but there are fine on iOS and on the Simulator). I also tried to override the Layout.overridesTabIndices(com.codename1.ui.Container) and Layout.getChildrenInTraversalOrder(com.codename1.ui.Container) methods in the Form, but nothing changed on Android.
I supposed two possible causes: the use of a Form inside a Form or, more probably, the fact that I replace all the TextFields and Pickers in the same Form (and other components). Maybe the fact that the inner Form is deeply changed results in a confusion for the Android mapping of the "next" button.
That's why my request: because I didn't find a way to make the "next" button useful, I'm asking how I can avoid that it's been shown.
Thank you
Nesting forms would probably mess with the focus traversal/tab order.
Normally you should be able to override public TabIterator getTabIterator(Component start) to return a blank iterator. I'd suggest doing the same for both the parent and child form to disable the "next" feature.
I have been using the following code to add a CheckBox as a side menu item (see below). But after I update my CodenameOne, Eclipse, and Java versions, this code does not work anymore (side menu does not show the checkbox with label "CheckBox", instead it shows a default side menu item with label "Command").
Should I use a different method to add a component to side menu?
public class SideMenuCheck extends Form{
public SideMenuCheck (){
Toolbar myToolbar=new Toolbar();
setToolbar(myToolbar);
Command sideMenuItemCmd = new Command("Command");
CheckBox sideMenuChkBox = new CheckBox("CheckBox");
sideMenuItemCmd.putClientProperty("SideComponent",sideMenuChkBox);
myToolbar.addCommandToSideMenu(sideMenuItemCmd);
show();
}
}
I have also tried adding a button instead of a check box as side menu item, but this code also failed to show the button on the side menu...
Thank you in advance for your help!
That approach for adding a component to the side menu has been deprecated for a while. You should use the API addComponentToSideMenu instead.
The reason this stopped working for you is the switch from the underlying SideMenuBar implementation to the new on-top implementation a while back.
I am working on a page where a left hand main menu has submenus. I try to hover to the main menu item, and it will show the submenu, and then I will click the submenu.
I am using below code:
#FindBy(id = "xxx")
private WebElementFacade mainmenu;
#FindBy(id = "yyy")
private WebElementFacade submenu;
Actions builder = new Actions(getDriver());
builder.moveToElement(mainmenu).perform();
submenu.waitUntilClickable().click();
I've tried other ways like:
action.moveToElement(mainmenu).moveToElement(submenu).click().build().perform();
It seems the problem is: when the test is performed when browser is in full screen, i.e.
driver.manage().window().maximize();
the main menu sometimes flash very quickly as if it's clicked really fast and recede, other times it appears not clicked or hovered to at all.
Because this hover and click active happens immediately after user navigate to the page, I add wait for element on the main menu, but it does not seem to work.
Any ideas how to solve the problem? I do not understand why it happens only when browser is in full screen mode. The only reason I can think of is the main menu element need more time to load.
EDIT:
Btw, the issue is very severe in Chrome. Firefox is better, but not 100% working either. It seems that even a simple hover:
mainmenu.waitUntilPresent();
Actions builder = new Actions(getDriver());
builder.moveToElement(mainmenu)perform();
does not always make the main menu display its submenu. I do not understand why it does not work.
I tried a simple project with 2 forms: Login and MainMenu
I made GUI with Codename One design:
I checked in StateMachineBase class, I think it for LoginForm (the first form)
And now, I want to click on Login button it will open MainMenuForm, but I don't know how to do.
Can you help me, maybe some tutorial or simple sample.
You can look at this: http://www.codenameone.com/how-do-i---handle-eventsnavigation-in-the-gui-builder--populate-the-form-from-code.html it covers pretty much everything.
The state machine base shouldn't be modified. Just select the login button and do one of two things:
Click the Action Event button and then when you are sent to the Statemachine class where the callback method would be added you can just use code like:
showForm("MainMenuForm", null);
Alternatively you can select the Command property of the login button and select that it would be a navigation command that will lead you to the main menu form. This is done entirely in the GUI builder with no code required.
I've got a "Main Window" containing quite a few things, including, in the status bar (at the very bottom of the window), a "Support" button, which the user can use at any time to open a window containing our support phone number, along with a little chat functionality if the user prefers to chat with us.
The problem is that if the program is displaying a modal dialog, the "support" button is not clickable anymore.
Stopping using modal dialogs is not an option ; I use them because I sometimes want to force the user into performing a specific task before I can do something else in the software.
What's the best way to let the user contact the support without having to close the current modal dialog?
Modal dialogs should behave as modal dialogs, the user won't expect to be able to click a button in the main window even if it were possible.
Your best bet is to put a support button on the dialog too.
Using a shortcut key instead of a button may be an option. The functionality could be factorized into a base form class like this :
public class BaseForm : Form
{
protected override bool ProcessDialogKey(Keys keyData)
{
if (keyData == Keys.F1)
{
SupportForm f = new SupportForm ();
f.Show();
}
return base.ProcessDialogKey(keyData);
}
}
Not using modal dialogs is an option. You can disable other parts of your interface during the required interaction to get whatever it is that you need out of the user.
The solution is to avoid situations where the user 'must' do something. Modal dialogs often get in the way if, for example, the user wants to quit the application right at that moment, or see something in a backgrounded window, or refer to another part of your application. Instead of using them, design your interaction so that if there is a required action/piece of information, it's folded into the application logic.
Think about website design -- modal dialogs are very rarely found on the web, and for good reason -- they disrupt the user's workflow unnecessarily. And yet plenty of sites have 'required' information.
Don't use modal dialogs; they are a shortcut to avoid a better design.