Issue with window cocoa xib - macos

I am working on a MAc osx application. I have created a window with different views: Scroll view, tab view etc., I have an issue with the window created. If I run the application,
First time - window is created as per the dimensions given in the XIB.
Second time - If I stop it, and run it again, the window is compressed - table view compressed. and thereby every other item is not at the right place.
Third time - And If I run it again, then it all looks fine, like it was at First time.
Fourth time - Corrupted like that of second time.
...Like this, I am getting wierd window output at alternate times.
Please help!!

Related

Changing size image in Oracle window and problem with Script Output

I have some aesthetic problems in Oracle SQL Developer.
First is moving the Script Output window. It seems to me it could have been moved on screen area. But some time I kinda moved the window somewhere and now I can't move it.
Second matter is that images moved from files explorer are unfitted to my preferences (I mean dimensions). Is here remaining solution is only to resize images in Paint and then moving to Oracle? Maybe these things are nothing for you but I can't stand mess on my screen.
Third screenshot showing my curiousal but annoying problem related with 2nd question. As you can see - the scale of this image is too high. I'd like to have whole image on some not too big area. But now I have bad-scaled image
You can't move the Script panel around, however the images looks like you're moving the SQL Worksheet, which contains the script output.
You can do that. IF you want to make it look 'all normal' or reset to the default desktop layout, use the Window menu, and choose this -
'Reset Windows to Factory Settings' - this refers to the SQL Developer windowing layout, not your OS, so it's safe.
SQL Developer UI will disappear, and repaint after a moment or two, hopefully back to 'normal.'
I'm sorry, I don't understand your 2nd question re: preferences and paint...

NSDocument with multiple windows -- Appkit dialog sheets jump to the wrong window

It is rarely used, but Apple's NSDocument documentation describes how to set up an NSDocument with multiple windows for a single document. I'm working on a database application that does this. Here is an example of a checkbook database document with two windows open. Each window shows a different view of the document, in this case a spreadsheet like view in the back, and a chart summarizing this data set in the front window. This example shows two windows for one document, but the user can create as many windows per document as they want, each displaying the same underlying document in a different way.
Everything works fine, except that if a system dialog sheet is opened (Save As, Print, Page Setup), most of the time (but not every time) the dialog sheet jumps to another window and attaches to that window instead of the current window, as shown in this movie.
Notice that although the dialog sheet attaches to the window containing the chart, it is correctly printing the content in the spreadsheet window. If I press Print, the correct content will be printed.
For printing, all our code does is call the NSDocument printDocument: method.
[NSApplication sendActionToFirstResponder:#selector(printDocument:)];
Page Setup code is also just calling NSDocument.
[NSApplication sendActionToFirstResponder:#selector(runPageLayout:)];
Our code is not customizing any of these dialog sheets, they are completely stock.
For the Save As command there is no code in our application at all, this appears automatically in the menu when the option key is pressed.
This problem appears in all versions of macOS supported by our application, from 10.9 thru 10.13. Perhaps this is an AppKit bug that is rarely seen because multiple windows with a single document is so rarely used?
This problem doesn't cause a crash, or prevent a user from doing what they want, but it is very visibly incorrect and reduces user confidence in the quality of the program.
For my reference this is #221 in the Panorama X issue tracker.
Implement/override NSDocument property windowForSheet.
The value of this property may be nil, in which case the sender should present an app-modal panel. The NSDocument implementation of this property sets the value to the window of the first window controller, or [NSApp mainWindow] if there are no window controllers or if the first window controller has no window.

Xcode menu item Editor / Add Model Version... missing

Every once in a while I try to add a new data model version, and the menu item is missing. It seems the Editor menu is supposed to change depending on the file selected, and this sometimes doesn't happen. It the past I've randomly clicked, cleaned, built, etc. and eventually it showed up again with me not knowing what happened. Today it seems restarting Xcode fixed it, but I don't know if that will always work. Below are two screen shots, the first showing the wrong menu, and the second showing the correct menu. My data model is selected in both cases. Has anyone else seen this? Is it a bug, or is there some setting or selection I'm missing?
From the color of that file navigator bar I can see that you did not select the datamodel file. You probably were in "Assistant Editor"-Mode and had a .h or .m file on the right side. The active cursor was in the right file too.
The selected file shows a darker shade of gray:
The not selected file uses a lighter shade of gray:
It's important to know that the file selection highlight in the left side bar does not change when you select a different file without using the side bar. Don't trust the sidebar when you are editing files.
Click into the data model file first and your menu will be like you expect it.
Unless your are selecting the menu super fast after selecting the file (possibly not giving Xcode time to swap it out) then I say file a bug report http://bugreporter.apple.com
You should give Xcode a few moments to swap the menu out though to determine what kind of bug it is, if it doesn't swap out after 60 seconds or so then it likely isn't just a performance issue). Make sure to include a system profile as I just checked on my and every time I switched to a data model it changed the menu accordingly.
Does the same thing ever happen with xib files? Any other file types you use that sometimes have different menus?

Hide window until the top window is displayed

I am facing a little annoying design problem. Not easy to give a title of my question.
I must display two windows, one over another one. The first one is a Cocoa window, the second is made with Qt. In the second window, an action is performed, but the user can choose to close this window. He must fall back on the first window.
To display my first window, which is actually a SFAuthorizationPluginView, I do:
[myview displayView];
then, to display the window made with Qt on top of first window:
QWidget* w = openMyScreen();
NSView* v = (NSView*)w->winId();
[[v window] setLevel:2003];
This works well, however there is a small delay before the second window is displayed. We can thus see for a very short time the first window.
I need that the second window stays on top of the first window, because the user can close the second window and must have access to the first window.
Any ideas on a trick how to hide the first window, just the time, the second window appears?
Thanks in advance
NSDisableScreenUpdates and NSEnableScreenUpdates (link) might be useful in this situation. The documentation says:
You typically call this function so that operations on multiple windows appear atomic to the user.
which seems to describe your situation.
A word of unrelated advice though: Don't go setting window levels willy-nilly. A window level of 2003 will likely cause the window to appear over things like the dock or even the menu bar, which would definitely be strange. You should stick to the standard levels declared in NSWindow.h unless you have good reason. NSFloatingWindowLevel might be appropriate (although I'm not sure what level the SFAuthorizationPluginView window is displayed at).
Starting with MacOS 10.4, you can use :
[NSWindow disableScreenUpdatesUntilFlush];

RBSplitView has delayed reload of autosaved view positions

I really enjoy using RBSplitView, an open source replacement for NSSplitView, but I have a problem in my shipping app and am experiencing it again in a new project.
The problem is I'm telling the RBSplitView to autosave its position state by giving it an autosave name. When my app launches the RBSplitView doesn't seem to honor the saved state till a second after the window is drawn.
I've spent the night trying to debug the behavior but have had little success. Anyone out there use this lib and have some advice?
You can scrub this quicktime movie to the issue at work:
http://media.clickablebliss.com/billable/interface_experiments/rbsplitview_delayed_autosave_reload2.mov
I've still been unable to figure out why this is happening but I do have a workaround.
First, make sure your main window is not visible at launch and then at the end of applicationDidFinishLaunching in your app delegate add something like:
[mainWindow performSelector:#selector(makeKeyAndOrderFront:) withObject:self afterDelay: 0.1];
The delay is the key. If you just tell the window to makeKeyAndOrderFront: I still see the issue. However as long as it has a beat of time it looks good.
This likely is happening because the RBSplitView instance needs to wait until it's first moment to get to set its frame to the autosaved value, which happens to be after the user can see it. This 0.0-delay trick simply delays showing the window until the very next runloop, which gives the split view a chance to do its magic (and other views) so that when the user sees the window, it's already nice and sexy. So just do the delay at 0.0 and you'll be fine.
I have a similar, but slightly different workaround in my app that uses RBSplitView. In applicationDidFinishLaunching:, I call adjustSubviews on the split view before calling makeKeyAndOrderFront: on the window that contains it. This seems to knock the split view in to order before it gets displayed on the screen.

Resources