Messages

1

NGUI 3 Support / Re: Wrong position for child objects

« on: July 01, 2016, 07:27:43 AM »

I have not experienced this problem, but you can easily control the position of your button.  For example:

1. main.transform.localPosition = Vector3.zero;

2

NGUI 3 Support / Bug: UIPopupList position bug when the panel is offset from the panel's parent

« on: June 29, 2016, 07:49:55 AM »

I found a bug in UIPopupList that occurs when the hierarchy looks something like this:

UIRoot
  PanelParent (empty GameObject)
    UIPanel
      UIPopupList

There is a bit of code in UIPopupList.Show() that causes the position of the popup's generated "Drop-down" object to be based on the panel's parent even though the "Drop-down" object is still a child of the panel.  This causes a problem if the panel's local position is not (0,0,0).

This issue can be reproduced in Example 0 by rearranging your hierarchy as described.  I used a game window that was sized around 1920x1080, with the panel's parent anchored to the top-left corner of the screen.  The panel's clipping option was set to None.  With this setup, the popup works fine if the panel and popup are in the top-left quadrant of the screen.  If you move the panel (along with the popup) over to the bottom-right quadrant of the screen, you will see that the popup's "Drop-down" object will be constrained to the top-left quadrant of the screen.

Commenting out this code near the end of UIPopupList.Show() fixed this issue for me:

1.                         Transform pt = mPanel.cachedTransform.parent;
2.  
3.                         if (pt != null)
4.                         {
5.                                 min = mPanel.cachedTransform.TransformPoint(min);
6.                                 max = mPanel.cachedTransform.TransformPoint(max);
7.                                 min = pt.InverseTransformPoint(min);
8.                                 max = pt.InverseTransformPoint(max);
9.                         }
10.  

3

NGUI 3 Support / Bug: OnKey not called while useMouse == false

« on: June 20, 2016, 11:08:14 AM »

This bug was causing problems in UIInput while useMouse == false.  Here is the fix:

In UICamera:

1. if (!useMouse && (key >= KeyCode.Mouse0 || key <= KeyCode.Mouse6)) continue;

should change to:

1. if (!useMouse && (key >= KeyCode.Mouse0 && key <= KeyCode.Mouse6)) continue;

4

NGUI 3 Support / Re: UIPopupList value always null

« on: June 16, 2016, 10:55:01 AM »

This was intentional. Popup lists for things like right-click menus would now allow for the same selection otherwise. For example right-clicking an item in Windward to bring up a popup list then choosing to link it in chat. First time would work, second time would not. Another example: right-clicking a player's name in chat and choosing to invite them to an instance. First time would work, second time would not. This was the reason for the change.

That makes sense.  I think the issue here is that popup lists are being used in two very different ways:

1) Popup list as a context menu.  This is what you have described.  It does not exist while it is not being used by the user, so accessing its current value outside of the context of the onChange event does not make sense.  The value doesn't really change, it is just temporarily selected.

2) Popup list as an option (such as screen resolution or video quality).  This is how I am using it.  It always exists, even if the user is not currently using it, so I want to be able to see what its current value is.  The value does change, and it is important to know when if it has actually changed or if the user ended up choosing the same option.  The value can also be set programmatically (not by the user).

5

NGUI 3 Support / Re: Irregular shaped (ie, not rectangular shaped) clipping

« on: June 14, 2016, 09:53:38 AM »

You can use the "Texture Mask" clipping option on UIPanel.

6

NGUI 3 Support / Re: Slider with offseted Foreground

« on: June 14, 2016, 09:48:36 AM »

Everything in your screenshot looks fine to me.  Perhaps there is a problem with the way that anchors may be set up on the foreground or background?

I suggest taking a look at the sliders in Example 0 to see if anything is different.

7

NGUI 3 Support / Re: Slider with offseted Foreground

« on: June 13, 2016, 05:38:43 PM »

Hi, I'm trying to create a slider in which both the foreground and backgrounds are not in the middle of the widget itself. This is usually the case when doing console UI, like in this example: http://pcgamingwiki.com/images/thumb/1/1f/Call_of_Duty_-_Black_Ops_III_audio_settings.png/300px-Call_of_Duty_-_Black_Ops_III_audio_settings.png

I have a UISlider which has a Label on the left and the Foreground/Background/Thumb on the right, like in the previous image. The problem is that the UISlider seems to be using the Foreground size, but not it's offseted position. So the slider moves when I click&drag on the middle of the widget, and not on the right, where the foreground and thumb are.

What's the best way to fix this?

Not sure if we have enough information to answer your question.  It sounds like there might be a problem with the way your slider widgets are arranged in the hierarchy.  If you post a screenshot of your editor with the hierarchy and inspector, then we might be able to help you out.

8

NGUI 3 Support / Re: UIInput is not deselected when a cancel key is pressed

« on: June 13, 2016, 02:30:35 PM »

While I was testing, I found that the UIInput in Example 12 worked properly after the Debug checkbox on UICamera was checked, such that the following behavior was observed:

1) Press the Play button with Debug unchecked.
2) Click on the input field and press escape.  The input field remains selected.
3) Check the Debug checkbox.
4) Click on the input field and press escape.  The input field is deselected.
5) Uncheck the Debug checkbox.
6) Click on the input field and press escape.  The input field is deselected.

When you tested this, did you have Debug checked?

9

NGUI 3 Support / Re: UIPopupList value always null

« on: June 13, 2016, 09:20:10 AM »

I also encountered this issue.

UIPopupList.value used to be accessible any time.  This was consistent with the way that other scripts work, such as UIInput.

Also, setting UIPopupList.value used to only trigger callbacks if the value actually changed.  Again, consistent with UIInput.  It now triggers callbacks every time, unless the value is set to null.

I prefer the way that it used to work 

10

NGUI 3 Support / Re: UIInput is not deselected when a cancel key is pressed

« on: June 13, 2016, 09:08:58 AM »

Seems to work properly here. I rolled the same change into 3.9.9. I run the example 12, click on the input field to select it, hitting Escape removes the selection.

Could this difference in behavior be caused by a difference in versions of Unity?  I am running Unity version 5.3.4p6.

11

NGUI 3 Support / Re: UIInput is not deselected when a cancel key is pressed

« on: June 13, 2016, 08:35:08 AM »

Thanks for your reply.

I changed the code as instructed, but the behavior that I described remains unchanged.

12

NGUI 3 Support / UIInput is not deselected when a cancel key is pressed

« on: June 10, 2016, 05:51:18 PM »

Hello,

When pressing a cancel key (set in UICamera), the currently selected UIInput is not deselected.  I set a breakpoint in UIInput.OnKey, but the breakpoint was never hit when pressing the cancel key.  This behavior can be reproduced in the Chat Window example scene (Example 12) in NGUI 3.9.8.

Please let me know what I should do fix this issue.

Thanks

13

NGUI 3 Support / Re: UIInput: order of input text and submit not maintained at low framerates

« on: October 31, 2014, 07:32:28 AM »

Thanks for your reply.

It sounds like we'll just have to live with it for now.  Maybe Unity will make improvements soon that will allow a fix for this. 

14

NGUI 3 Support / UIInput: order of input text and submit not maintained at low framerates

« on: October 29, 2014, 09:50:24 AM »

When there happens to be a hitch or otherwise low framerate while the user is typing input, the order of their submit command relative to the rest of their input can change.  For example, if the user types "Hello World" and then presses Enter while experiencing poor performance, their input might be received instead as "Hello W", Enter, "orld".  Looks like this is due to the separate implementation of the submit key in the OnGUI method (via the UIInputOnGUI class).  This is probably true for other non-text input (such as backspace, arrow keys, copy, paste, etc.) that are processed by UIInputOnGUI.

Ideally, everything would happen in the order that the keys were actually pressed regardless of any performance issues.  The fact that it does not even further punishes users on lower-end machines that regularly experience poor performance.

Any ideas about how to remedy this problem?

15

NGUI 3 Support / Re: Changes to UIPanel alpha do not affect alpha of UIInput caret/selection

« on: March 06, 2014, 04:15:08 PM »

After updating to the latest version of NGUI, the problem persists.