I need help with Xcode 4. I started something very simple, created a cocoa project and added a Window object and called it preferences.
Then in order to access this new window I linked it with the menu item "Preferences" action makeKeyAndOrderFront.
Just that, then when I run the application, the first time I click on the Preferences menu item, the preferences window open just fine ... after I close it and click again on the preferences menu item, then application crashes with EXC_BAD_ACCESS on the main.m
Does anyone knows what is the problem?
I had exactly the same problem, and I suspect we were both following the same trail of sparse tutorial information out there to make a Preferences window like Apple's.
I solved this issue just now by just setting window = nil, and not trying to get fancy with [window autorelease]. As I tested, using [window release] would cause the issue instantly, while [window autorelease] would create that second-time crash.
I Had the same behaviour. After some tests I understood that the problem is that the second time you click the preferences menu you send a message to the window that has been released (the object does not exist anymore). You can verify it by adding the 'NSZombieEnabled' environment variable set to 'YES' on the 'Arguments' Tab of your executables from XCode.
I solved this issue deselecting the 'release when closed' check in the interface builder for the window used as the preferences window.
Bye. Peter.
Related
I have a very strange problem. The application is based on Qt C++. There is a TabWidget whose tabs are created dynamically. The tab contains QtMainWindow in ActiveX widget. When multiple apps are started, the selected one works fine. But when another tab is selected, it becomes unresponsive.
When I minimize the Application and then maximize again then the tab starts working fine. I tried with setFocus, activateWindow, showNormal and setActiveWindow but nothing is working.
Can somebody help me in this issue?
The likeliest cause of the app becoming unresponsive is something that stalling the execution on the main thread. With running the project from/ or attaching to Visual Studio debugger (better debugger than the one used by Qt Creator) try to get your app in such unresponsive state. Now look at Main Thread in Threads view (select one), also look at Call Stack view. Where does the execution stall?
The log in Output View is also helping to recreate the context of how to get there. You can see Qt and your own debug output there.
While debugging I found that the App was not syncing because of missing WA_Mapped attribute. My problem was just opposite of the below issue. When I used to maximize after minimize, the App used to become responsive. Finally setting the attribute WA_Mapped at different places (trial n error) fixed the issue.
widgets freezing after minimise window
Thanks for #AlexanderVX response.
I have a window, a label, a button, and an NSObject.
The first thing I want to do is change the NSObject's class to that of my custom controller.
The thing is, I can't seem to select it. Whatever object I select, the inspector panel says "No Selection". Why? I'm baffled.
accepted answer did not work for me, but answer by 'NSExplorer' did (In Xcode4, the new interface builder says "no selection"). i slightly modified answer from 'NSExplorer'
.. switch to another (non IB) file in the current tab
.. switch back to the IB file (eg. Main.storyboard)
the Attributes Inspector will magically show in the new tab.
I just had to close the assistant editor and the debug area and then it magically showed up. If you don't have the assistant editor open then all you need to do is open it, then close it again. That should fix it too.
If you don't know what the assistant editor is I have highlighted it in red:
Xcode 7.2
The interface builder in XCode 4 is incredibly buggy. I'm also having frequent issues like this. Have you tried closing XCode and re-opening your project? Sometimes, resizing the entire XCode window also seems to reset the interface builder layout.
Make sure you're selecting the objects from the XIB document panel (Where it says "Objects") on the left. Sometimes clicking the actual UI controls doesn't catch in the inspector panel, for whatever reason.
For me, I had the bottom, debugger stretched all away to the top. It said "no selection." By Taping on hide/open bottom debugger twice, you can get the main component back again.
If you have multiple windows, close the storyboard file and open it again, it worked for me
I've created a new dialog using Qt Creator (version 4.7.0) - one of the templated forms (with an OK and a Cancel button).
I want the user to enter some data on the form and then when they click OK, it saves that information. So I had a look, and saw that when the OK button is clicked, it sends and signal to the dialog's accept slot.
So I right clicked on the dialog in the design view, and selected "Go to slot...". I clicked on the "accepted" option, which dropped an on_Dialog_accepted() method into the dialogs class. However, when I run the program and open the dialog, I get an error in my console saying QMetaObject::connectSlotsByName: No matching signal for on_Dialog_accepted()
So what did I do wrong?
I've found documentation on the connectSlotsByName - but nothing about any obvious pratfalls that an inexperienced Qt-developer can get themselves into.
Right-clicking on the dialog in the design view prior to selecting "Go to slot..." made a connection from the dialog's signals to the dialog's slot, which doesn't work with QMetaObject::connectSlotsByName(), since that method searches for all child objects, but not for the object itself.
What you wanted to do actually is right-clicking on the OK button, then selecting "Go to slot..." from there. It will then create a slot with the name of your button widget, and the connection will be made correctly at run-time.
It makes no sense that QtDesigner lets you select "Go to slot..." from the Dialog. You might want to file a bug to Qt's devs for that.
It is basically just as Fred explained: you did not do anything wrong. This is a QtCreator bug. And a pretty old one for that matter. Unfortunately, even two years later nothing in that regard has changed.
The assignee of the aforementioned bug decided to sort of redirect it to this QtCore bug, which simply asks for QMetaObject::connectSlotsByName() to be changed in a way that it also processes the passed object and not only its children (thereby fixing the QtCreator issue).
I had a look at the source and submitted a trivial patch.
Update: The patch got accepted, meaning this bug is going to be fixed in Qt 5.1. Note: it is not relevant which version of QtCreator your are using but which version of Qt you link your code to.
I have an AIR application with a system tray icon. When clicked it shows and activates the app. This is working as expected when the app is hidden (docked), however if I select another application so my app is in the background clicking on the system tray icon does nothing.
Oddly I also have a contextual menu on the system tray icon, which has an option to restore, this calls the same event handler as ScreenMouseEvent.CLICK, yet works.
I expect it's something to do with the contextual menu changing the focus, perhaps it's a bug in how AIR works with the system tray, perhaps it's just something I'm missing. Would be good to know if that's the case.
Thanks in advance
Rob
//instead of just calling
activate();
//call
nativeApplication.activate()
//or even better
nativeApplication.activate(nativeWindow);
Update based on OP's input: if you have multiple windows open for the application, use:
nativeApplication.activate(nativeApplication.openedWindows[0]);
If you are not in the main WindowedApplication class, you can use the static property NativeApplication.nativeApplication to get a reference to the singleton object.
WindowedApplication.activate()
Activates the underlying NativeWindow (even if this application is not the active one).
NativeApplication.activate(window:NativeWindow = null)
Activates this application. If the operating system allows activation, then the specified window is activated and brought to the desktop foreground; that is, in front of the windows of other applications. (If the window parameter is null, then a visible window of this application is activated.)
livedocs is not clear on why this is happening. It says activate() activates the underlying native window - one would expect it to be brought to the front when it is activated, but that's not happening.
I have a problem with Qt modeless dialog in Solaris 8/10 machine using CDE (Common Desktop Environment).
The dialog serve as drawing panel/popup that required user to choose the tools from main application before proceeding to draw on it. The problem is whenever user click on main application toolbar, then the dialog will goes behind the main application.
Notice that this is the behavior pertaining to CDE only, Open Windows enviroment or Solaris Java environment don't cause this issue.
My question is how can I make it always on top of its parent (main application)?
I've tried to pass in WX11BypassWM flag to the dialog, to by pass window manager, but then the border and frame is gone which cause the dialog to not drag/move-able.
Update 1:
With regard to Andy's answer:
I've tried Qt::WStyle_StaysOnTop, but it doesn't work.
I tried also to combine:
WX11BypassWM | WStyle_StaysOnTop | WStyle_Title
and other combinationa of WStyle_DialogBorder, WType_TopLevel etc, it only stays on top if WX11BypassWM is passed in.
But whenever WX11BypassWM is passed in, the dialog shown up will not have border nor the tittle bar.
Which means it's a unmove-able tittle-less dialog.
Update 2:
Since I can't find a solution for this issue, for the time being, I resolve it by resizing and reposition the main application and the modeless dialog to be side by side.
This at least will let user navigate in both interface.
Anyone if has a better suggestion then let me know.
I'm not sure I understood your question, but, wouldn't it be possible to use :
Found in QtAssistant :
enum Qt::WindowType
flags Qt::WindowFlags
Qt::WindowStaysOnTopHint :
"Informs the window system that the window should stay on top of all other windows."
I hope it helps a bit !