I have a two modals that I'm designing to go over my project in Unity, one for a quick tutorial and one for more information about the project, I also have an animation playing in the background.
I'd like the animation to pause whenever the modals are active and over the top of the animation, if you can't see the animation, why have it playing? Exactly.
My code so far doesn't work and I'm unsure why.
using UnityEngine;
using System.Collections;
public class ModalPauseController : MonoBehaviour
{
public GameObject tutorialModal;
public ScrubberAnimationController nac;
public void TutorialModalIsOpen()
{
if (tutorialModal.activeInHierarchy == true)
{
Debug.Log("The tutorial panel is active!!");
nac.UserClickedPauseButton();
}
}
}
nac.UserClickedPauseButton refers to another script where it pauses the animation.
So far whenever I toggle the active state of the modals, whether it be via the inspector, or in game, I no feedback in my debug.
It's quite tricky writing code like that, because if you think about it
the code itself will be not active !!!
As a rule say you have a panel "X" which is a popup or something like that - something which comes and goes.
The rule is you must have the "controller" for that thing
on some other item, not on itself!
Here's an example:
The "megabomb" is a popup sign which goes on and off. There it is on
and there it is off. There's a script which controls the megabomb on-offness.
Notice there is a "wrapper" for the megabomb item. In UI the "wrapper" is very simply an empty panel. It is invisible. Note that the wrapper always stays on.
The script goes on the wrapper - that's it.
Note that very commonly the "megabomb" item itself has a "wrapper" - a gray transparent background. So, when the popup appears, the game behind goes all gray and you have the popup over that. Don't forget in that case the gray background would be labelled "megabomb" in this example and the actual popup green (or whatever) panel would be below that. (Indeed the popup panel itself will very likely have many parts -- images, buttons, borders, etc etc.) Do not try to use the "gray background" as the "wrapper which holds the script. You need a completely separate wrapper "outside of everything" which does nothing other than hold the script.
{BTW this is yet another thing which screws up experienced-developer-who-are-new-to-Unity. Normally you'd have "some other class" run the popup, but there is "no other class" in Unity - everything is a singleton if you will, since it is an ECS system, not normal OO. You have to literally have another game object (the one labelled 'wrapper' in the example) which controls the game object in question (the one labelled 'megabombs' in the example). AND it has to be always active.}
Note - if you prefer the "controller script" can actually be anywhere else (it does not have to be on an game object "holding" the item in question). However certainly at first I encourage you to use the system of putting it as a "wrapper" as shown, it has many advantages. (Not to mention ultimately it might be a Prefab, etc etc.) Definitely do that when starting out.
It's just "one of those things they don't mention" about Unity: very often many many things in your scene will need a "wrapper" object. (The same is true for other reasons such as positioning, relative rotations, etc, too.)
BTW as I mention in a comment. If you are making a popup, it must be done with Unity.UI (ie, click "add canvas" - always remember to set to 'scale with screen size' , then click "add panel", then click "add text").
Related
I originally had code that set the focus to the first widget in a dialog, in the onInit method. But there were problems with it: if I pressed TAB, indeed focus moved to next control (wxTextCtrl), which got the blue 'focus' color, but the 'focus' color/highlight was not removed from previous focus widget. So now it looked like both first and second control had focus at the same time...
When cycling manually (by pressing TAB) full circle (till last control and then wrap around to the first), suddenly all worked well. That is, when moving focus from first control to next one, the first visually lost focus (blue color was removed) as it should. From now on, only one item had the focus color/highlight.
So instead of setting focus on the first control, I tried a different approach: I set the focus to the last control in the dialog, which is always the OK button. Next, I want to emulate programmatically that a TAB is pressed and received by the dialog. So I wrote this (inside Dialog::onInit):
m_buttonOK->SetFocus();
wxKeyEvent key;
key.SetEventObject(this);
key.SetEventType(wxEVT_CHAR);
key.m_keyCode=WXK_TAB;
ProcessWindowEvent(key);
Now the focus indeed moves away from the OK button, but it does not wrap around to the first control.
Only when I manually press TAB after the dialog opened, the first item gets focus.
Question: why does this wrapping around to set focus on first widget not work with the code shown above?
First of all, your initial problem is almost certainly related to not calling event.Skip() in one of your event handlers, see the note in wxFocusEvent documentation.
Second, you can't send wx events to the native windows, they don't know anything about it. In this particular case you can use wxWindow::Navigate() to do what you want, but generally speaking what you're doing simple can't, and won't, work reliably.
When I double-click on an animator controller to launch it, the animator tab appears, but when I run the editor, I don't get the usual flow, operations, etc... I only get a static view of the states and transition arrows between them. My parameters do not show the changes they go through either.
I have multiple animations and can switch between them when certain game conditions occur, but nothing really shows when I do so, to see the flow of control, what happens, what goes wrong, the switching, the progress bar, etc...
I have the latest Unity 5.2.0f3 so I wondered if it is just me or others are having a similar problem...
What we need to do is this: Once we hit the play in the editor mode (and have the animator window docked on one side, of course) we just go and click the object in the hierarchy for which we want to analyse the animation flow. And the animator window will start showing the states and the progress bar.
Also, after upgrading to Unity 5.2, it is worth checking the values that were previously set for transition states, for example if vSpeed is greater than 0.1 then start walking. All my set values were messed up; i.e. changed.
I'm working on a applescript to update the content of a document in Microsoft Word. The updating process is quite long (might take more than 5s). So I want to prevent users to change anything during the updating. Do you know whether Microsoft or Applescript a function like that?
In Windows, I can just display a User Form (which is a dialog telling that "we are updating... ") and close that form when it's done. However, I don't know whether I can do the same in Mac (with Applescript alone).
When you say "applescript", I don't know if you mean "plain" applescript or the AppleScriptObjC version. If you mean the latter, then I know ways to do it.
One way I've used during slow processes is to put an overlay view over the whole content view of the window. I make it translucent white to partially obscure the window, and put some kind of message (and maybe a progress indicator) on it. You can just use an NSBox (of the custom type) in IB to make this, and then make a subclass of NSBox to color the view and override mouseDown:. MouseDown:, doesn't need to have any code in it, just by overriding it, you capture any key and mouse events so they don't accumulate on the event queue, and get used by the view below after your overlay goes away. Here's code I've used:
script Overlay
property parent : class "NSBox"
on awakeFromNib()
set overlayColor to current application's NSColor's colorWithCalibratedWhite_alpha_(1,.8)
setFillColor_(overlayColor)
end
on mouseDown_(theEvent)
--log "mouseDown"
end
end script
I have this view as the top most view in the view hierarchy, and set its hidden property to true until I want to show it.
In spite of there being a Human Interface Guidelines document (HIG), a lot of high quality Mac desktop applications use custom controls. My question is what is the best approach to start subclassing controls for Cocoa development? It surprises me how little (good) information there is on this topic. What path is the best to follow so you don't end up with a nice but half broken control?
Here's a checklist:
Make sure your control works correctly at double resolution. Use Quartz Debug to test this. You'll want to test both drawing sanity (in all states—normal, selected, pressed, disabled, and any others) and operation sanity (that hit testing matches where things appear on the screen/other destination device).
For extra credit, make sure your control works correctly at 1.5 (or some other, similarly non-integral) resolution.
Test how the standard control works when clicked. You'll probably do this anyway. Do as the standard control does.
Test how the standard control works when half-clicked (mouse down inside, mouse up outside).
Test how the standard control works when dark-side-of-the-clicked (mouse down outside, mouse up inside).
Test how the standard control works when dragged within.
Test above four with the other mouse buttons (right and middle).
Test what the standard control does when you scroll with a scroll wheel. Also test shift + scroll and, on a mouse that has them (e.g., most Logitech mice), scroll left/right buttons.
Test what the standard control does when you two-finger scroll in each axis and in both axes.
Test what the standard control does when you pinch and when you unpinch.
Test what the standard control does when you swipe with three and four fingers in each axis.
Test how the standard control works with “Full Keyboard Access” turned on. Can you tab into it? Can you press it with the space bar? Can you enter it with the return key? Can you tab out of it?
Test how the standard control responds to Accessibility queries. Use Accessibility Inspector. See the Accessibility Programming Guidelines for Cocoa for information on responding to accessibility queries and messages in your control.
Test your app—including, but not limited to, your custom controls—in VoiceOver. Blindfold yourself and try to use the app with VoiceOver alone.
If applicable, test printing your view. You can print to Preview if you don't want to kill a tree for your development process.
Test printing in other paper sizes. If you're in the US, test A4; otherwise, test US Letter. Test still other paper sizes (such as Legal and A3) if you're feeling thorough.
If you're implementing a scroller (poor you), test that your scroller responds correctly to the “Jump to the (next page|spot that's clicked)” preference in the Appearance pane in System Preferences. “Correctly” means it should do what the user selected.
Make sure it correctly implements all four scroll-arrow-position settings: One at each end (Mac style), both at the lower/left end (NeXT style), both at the upper/right end, and both at each end (power user style). As always, you need to both draw correctly and hit-test/react correctly. (Suggested by #radiofreelunch/by David Dunham)
Also, if you're implementing a scroller, make sure it responds to the “Smooth scrolling” preference correctly.
Test that it responds to different scrolling speed preferences correctly.
If you're implementing a text entry field of some sort, or any view that responds to some sort of special hot key (like Enter to send a message in an inputline), test right-to-left (Hebrew/Arabic) text input and alternate input methods. The Character Viewer is a good start.
Also, test that you don't break ctrl-q. For example, ctrl-q, tab should always enter a tab character. The same typically goes for option + (key), such as option-return in an inputline.
Test that it responds to different key-repeat preferences correctly.
If you implement any custom keyboard shortcuts (⌘ + zero or more other modifiers + one or more character keys) by means other than Cocoa's standard menu shortcut handling, test your custom shortcut behavior under Dvorak. There is no faster way to sour our perceptions of your app than to respond to ⌘' by quitting.
Show your app to users who've never used it nor seen any mockups before. Disqualify programmers. If they don't recognize your control as a (whatever it's supposed to be), redesign it. If you ever say “the scroller is over here” or “you need to click that”, you instantly fail.
Test that your control responds (or doesn't respond, if responding would be dangerous) when your app is in the background. (Suggested by #chucker.)
Test that your control responds, but does not bring the app forward, when your app is in the background and the user clicks on it with the ⌘ key down. (Suggested by #chucker.)
Test resizing your view. Among other things, this will ensure that you set the autoresize mask correctly. You're also looking for drawing bugs—distorted elements, gaps, etc. (Part of this suggested by #Bagelturf.)
If your control is, in fact, a control, send it sizeToFit and make sure that it does the right thing. (Suggested by #Bagelturf.)
If you work with mouse coordinates, don't assume that they will be whole numbers. Ensure that you handle fractional numbers, zeroes (positive and negative), and negative numbers correctly. (Part of this suggested by #Bagelturf.)
You might also consider splitting your control into a control and a cell. In the latter case, also perform all of these tests on your cell embedded in an NSMatrix and in an NSTableColumn.
If your control has a menu, test what happens when the control is at one or more edges of the screen. The menu should move over to not fall outside screen space.
If your control has a menu, test that the user can enter it with the down arrow key when using “Full Keyboard Access”. If it is also a text field (like a combo box), test that this only happens when the user presses the down arrow at the end of the text; otherwise, normal text field behavior should rule: Pressing down on a line that is not the last line should move the cursor down a line, and pressing down on the last line should move to the end of the line.
If your control has a menu, test that it stays open when clicked and does not immediately close when held open. There is a function you can use to do this correctly, and it is available in 64-bit.
If your control has a menu, test that it is navigable (all four arrow keys + Home, End, Page Up, Page Down), usable (spacebar/return press action), and cancellable (esc) with the keyboard.
Hard to add anything to Peter's list, but if you're doing a scroll bar, be sure it handles all the deviant placements of the scroll arrows (like DoubleBoth).
I'm not big on creating GUI's, and generally my philosophy is: I don't create them, or I make them as simple as possible (and convince myself that it's better for usability :)
For my current project, I'm using Qt from Python (PyQt), and I want to start adding some GUI elements without cluttering the interface.
My idea is to create these elements as sort of floating-shaped-widgets that only appear when necessary; pretty much like the status bar (and find bar) in chrome.
Is there any standard api that enables creating this kind of interface?
This is not very complicated. If you want something like the status bar in Chrome you just need to have a QFrame at the bottom of your windows and show or hide it when you need it.
You have 2 options here, add is as part of your window layout so all the items move up when it is shown. Or you can have if floating, so it will be shown on top of the items. For the second option you need to create the QFrame with the window as parent and then in the window resizeEvent set the geometry of the frame.
This is an example of the second approach:
void MyWindow::resizeEvent(QResizeEvent* event)
{
frame.setGeometry(0, this->height() - frame.sizeHint().height(), this->width(), frame.sizeHint().height());
}
I hope this helps.