actionbar in android have different behavior for support lib version? - android-actionbar

I find if in the build.grade giving different support lib:
compile 'com.android.support:appcompat-v7:22.0.0'
compile 'com.android.support:support-v4:22.0.0'
or
compile 'com.android.support:appcompat-v7:20.0.0'
compile 'com.android.support:support-v4:20.0.0',
the actionbar have different behavior.
app icon is not showing up in v22.0.0
menu is not showing up
in the overflow menu, while in v20 it will.
In the activity, we have the below code.
#Override
public boolean onCreateOptionsMenu(Menu menu) {
getMenuInflater().inflate(R.menu.menu_main, menu);
return super.onCreateOptionsMenu(menu);
}
The behavior of v20.0.0 is what I want.
If I want v22.0.0 have same behavior as v20.0.0, what I should do?
Is this because in android 13, some behaviour on actionbar changed?

You must return true in onCreateOptionsMenu() or the menu won't show. That's why you don't see it because the super method returns false. This has not changed and is well-documented.
Other possible reasons why your menu does not show up:
Your XML menu resource does not use the package prefix attributes of AppCompat but the "android:" attributes instead.
You are using a Toolbar in your Layout but you don't register it as main ActionBar.
A bug in this version of AppCompat (but I doubt it). Latest version at this date is 22.2.0.
Since v21, AppCompat implements the Material design behaviour and in Material design the app icon is not shown by default.

Related

QT QApplication:setFont() Questions

In my main.cpp I set the font of the application like so:
//Font
QString fontPath = ":/data/COUR.TTF";
int id = QFontDatabase::addApplicationFont(fontPath);
QString family = QFontDatabase::applicationFontFamilies(id).at(0);
QFont default_font(family);
default_font.setPointSize(10);
QApplication::setFont(default_font);
This works, mostly. For whatever reason all of the application that I can see correctly applies this font except for the very parent widget, QTabWidget.
I also have this snippet of code that is activated on a button press, inside a MainWindow function:
QApplication::setFont(QFontDialog::getFont(0, QApplication::font()));
When activated during runtime, this error is produced:
2017-06-13 21:10:14.622 MYAPP[36930:4140590] Layout still needs update after calling -[QNSPanelContentsWrapper layout].
QNSPanelContentsWrapper or one of its superclasses may have overridden -layout without calling super.
Or, something may have dirtied layout in the middle of updating it. Both are programming errors in Cocoa Autolayout.
The former is pretty likely to arise if some pre-Cocoa Autolayout class had a method called layout, but it should be fixed.
(Edited a little for visual clarity)
I've looked at this bug report, which shows the exact same error and a similar-ish code, it may be relevant: https://bugreports.qt.io/browse/QTBUG-58699
Their code:
QColorDialog::getColor(QColor(1., 1., 1.), myWindow, "My Title", QColorDialog::DontUseNativeDialog);
That error is not produced by the MainWindow function if I remove the main.cpp settings, which makes me doubt its actually this bug. In addition, the MainWindow function correctly applies the font chosen to all but a few (seemingly) random buttons.
They (From the bug report) are on OSX 10.11.6, I am as well. They reported it for QT 5.8, I'm experiencing it with QT 5.9 and 5.8. If this is the case, this doesn't surprise me, as the bug report does not indicate it has been fixed. I can reproduce it on the QT Creator built debug version, and a statically built release version.
So my question boils down to these points:
1) Why does the main.cpp font code not work across all widgets?
2) Why does that MainWindow function not override the main.cpp settings?
3) Why does that MainWindow function (With the main.cpp part removed) not apply the settings to the entire application?
4) Are there better/easier ways to accomplish what I'm trying to do? (Set a font on application start, and provide a way for the user to customize it later)

How to debug UI in iMessage Extension?

I am developing iMessage Extension, but i am facing some UI issues. But I am not able to debug UI as like iOS Application.
As extension run on com.apple.MobileSMS(iMessage App Container).
So, is there any way to debug UI of iMessage Extension ?
There is no option to Debug UI hierarchy in iMessage till
Xcode-8.1 . It shows the black spaces in the UI while tap to DEBUG iMessage UI .
Unfortunately as of now Xcode 8.3.2 Doesn't support View Hierarchy Debugging for extensions in general (At least from my experience)
However there is this Software called Reveal by Itty Bitty Apps
This is probably even better than Xcode's native View Hierarchy debugger since it also displays additional detailed stuff like broken constraint, ambiguous width and height and it can also point out at which view it has these issues, and you can also change view properties while in runtime.
Give it a try.

CMFCMenuBar and TestStack.White win.MenuBar is null

I'm trying to use TestStack.White to Automated an MFC Application (for UI testing purposes)
When using TestStack.White with an MFC Application written with CMFCMenuBar (the later Docking framework MFC) I noticed that code like the following fails due to window.MenuBar being null
var menu = window.MenuBar.MenuItem("Window");
menu.Click();
I know I can overcome this issue with the following
TestStack.White.UIItems.MenuItems.Menu windowMenu = win.Get<TestStack.White.UIItems.MenuItems.Menu(SearchCriteria.ByText("Window"));
windowMenu.Click();
But what I really want to do is get the ChildMenus so that I can check the list of windows open in the window menu, but the windowMenu.ChildMenus is empty
I am pretty sure this is because the menu is really a toolbar/toolstrip (dockable)
Does anyone know how to get the menu items (Tile,Cascale,Window1....) from the Window Menu
Has anyone else seen this issue or found a work around?
Thanks in advance
Paul
Yes, the MFC feature pack menu is really a toolbar with buttons. And it is fulfilled using a different process compared to the old style menu.
In your CFrameWndEx derived class, for getting the menu bar you can do:
CMFCMenuBar *pMenuBar= m_Impl.GetMenuBar();
Then it depends on what to do with it. For example, if you want to get the CMenu object that constitutes the menu bar you can do:
CMenu* pMenu= pMenuBar->GetMenu();
If you want to remove some of the menus, you can do (Notice the reverse order):
pMenuBar->RemoveButton(4);
pMenuBar->RemoveButton(3);
You can not get the menu the typical way by YourCFrameWndExDerivedClass::GetMenu() because these new MFC Feature Pack classes intentionally do SetMenu(NULL) when initializing the main frame, as you can see in the call stack:
I am not absolutely sure, but I think you won't also be able to do the override YourCFrameWndExDerivedClass::OnInitMenu() as you could in the old style menus. But you can still use the YourCFrameWndExDerivedClass::OnInitMenuPopup() overrride.

Visual Studio MFC Toolbar Editor icon order won't update

I've been trying to create a custom toolbar in a MFC project in Visual Studio 2010. I've been following the Sketcher tutorial in Ivan Horton's Beginning Visual C++ 2010. The problem I'm running into is that the toolbar doesn't update to reflect the order and spacing of icons I have created.
I've created a small screenshot to demonstrate the problem:
In the background is the visual studio toolbar editor with my desired toolbar configuration. In the foreground is the actual app, which does not reflect the spacing or order of icons I've designed. It does reflect NEW icons being added, and the icons work fine, but I just can't seem to get them to re-order or appropriately space themselves. They just append to the end in whatever order I create them.
I've tried the rudimentary techniques of restarting both VS and windows, but to no avail.
Any tips on getting it to play nicely? Lacking that, is there somewhere to manually view or edit the code generated by the toolbar editor?
For starters, if you create an MFC SDI/MDI project in VS.NET 2005, there is no such issue. It happens in VS.NET 2008 and 2010.
In fact, your rearrangement of the standard toolbar does takes effect. It's just not showing you the default state. To restore the state: click the small arrow button at the end of toolbar -> Add or Remove Buttons -> Standard -> Reset Toolbar.
Though I'm not 100% sure why it happens like this(design like this or a bug), there is a way to work around it and it works:
Add following code to the end of CMainFrame::LoadFrame(...)
BOOL CMainFrame::LoadFrame(UINT nIDResource, DWORD dwDefaultStyle, CWnd* pParentWnd, CCreateContext* pContext)
{
...
// Explicitly restore toolbar state
m_wndToolBar.RestoreOriginalstate();
return TRUE;
}
I recommend you to contact Microsoft support engineers as there's little resource on the web.
The reason could be that the toolbar state is already loaded from the registry whenever your application starts. So the framework reads the toolbar state and adds the new buttons to the end. Is there a Workspace key in your Registry and did you try to delete it anytime you make changes to the toolbar? The key should be at a location like HKEY_CURRENT_USER\Software\MyCompany\MyApp\Workspace
The values for MyCompany and MyApp are usually set in InitInstance. Always calling RestoreOriginalState() would break the code to allow user modifications to the toolbar.

How to show available windows in the Window menu

I have a MFC MDI application that I've recently ported from VS2003 to VS2008, and at the same time moved from Stingray Objective Studio 2006 v2 to v10.1. On the previous versions of my application, if I had more than one view open, the Window menu would be populated by an enumerated list of available views, e.g. 1 MyViewA, 2 MyViewB etc... If I had a large number of views, I would also get a Windows... menu option to allow me to select a view. This no longer happens, which is breaking some of my GUI level regression tests. My guess is that this functionality was implemented by either CMDIFrameWnd or SECMDIFrameWnd but I couldn't find a reference to it in the documentation. Does anyone know how I can get this functionality back.
First thing I'd do is create a new MDI application with the ClassWizard and check if the functionality you're missing is present. If so, poke around and see if you can tell what's different. One place to look may be the menu resource for the main menu.
If there is no in-built functionality to provide what you need, you can dynamically build the menu with the following pseudocode:
foreach registered CDocumentTemplate
foreach document
foreach view
{
if (numberOfWindowMenuItems < 5)
{
Add menu item
}
else
{
Add "Windows..." menu item
break all loops;
}