Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - schellenberghq

Pages: [1] 2 3
I found that if I needed to comment out these lines from EventDelegate.cs script starting on line 482 and down. There is two times that this appears.

  1.  #if UNITY_4_3 || UNITY_4_5 || UNITY_4_6
  2.                                 object[] objs = type.GetCustomAttributes(typeof(ExecuteInEditMode), true);
  3.  #else
  4. //                              object[] objs = type.GetCustomAttributes(typeof(ExecuteInEditModeAttribute), true);
  5.  #endif
  6. //                              if (objs == null || objs.Length == 0) return true;
  7.                         }

My apologies, I thought this was an NGUI issue, or perhaps that if Unity broke it, this might have to be updated in the NGUI framework.

Error from console:

Assets/NGUI/Scripts/Internal/EventDelegate.cs(485,81): error CS0246: The type or namespace name `ExecuteInEditModeAttribute' could not be found. Are you missing a using directive or an assembly reference?

Apparently in Unity 5.0.0b17 ExecuteInEditModeAttribute breaks.

NGUI 3 Support / Re: Tab navigation works in editor but not browser.
« on: November 03, 2014, 11:02:01 AM »
Tabbing works stand alone, and in editor.

Webplayer still doesn't work, even if I use Up/Down arrows for the events. It's like NGUI is eating the event or something. This is only the case for UIInputs.

#Edit: In fact I'm fairly certain NGUI is eating the event somehow, because when I use the up/down arrow, instead of listening to my logic, the i-beam moves to the beginning or end of the typed input. How can override this behavior, or add onto it?

Yet... why would it only seem to override in the web player? Bwah...

Although somehow you have it working, but only if I use the UIKeyControl... then somehow tab works.

#Edit2: I ended up using Left+Control as Shift+Tab, and Right+Control as Tab.

NGUI 3 Support / Tab navigation works in editor but not browser.
« on: October 22, 2014, 10:02:41 AM »
I've created my own tabIndex type navigation.

For some reason though, in the Unity editor pressing tab works just fine, even when a UIInput is the current selected object. However once I build for web and try it in the browser, suddenly my tabs stop working. However if I add a KeyNavigation script from NGUI it kind of works better.

Is NGUI doing something cancel my Tab presses because the UI element doesn't have a KeyNavigation script? It's just odd that it doesn't matter because it works in the editor, but not in the browser.

Any ideas?

NGUI 3 Support / Assigning Delegates via Inspector vs Code
« on: October 21, 2014, 12:01:57 PM »

Do you prefer assigning event delegates using the Inspector or via Code.

I ask this because when I first started my project, I assigned all the events via inspector.
As the project progressed, I found I needed to assign some events via code because they came dynamically.
And now, I find myself wanting to go back and assign via code all the events I am currently doing via Inspector.
I came to this conclusion because I decided it was much easier to maintain and fix/alter these events via code than it was via inspector.
For example, if I replace my Create Button, I now have to reassign the event in it's OnClick, and if it has multiple events than it's spending a few minutes rewiring all those events back up.
However, if the events were assigned via code, I would simple have to reassign the new Create Button to my script via the Inspector.

I guess it's about consistency. I'm just realizing that I consistently assign UI elements via inspector, as opposed to trying to use FindGameObject like I used to along time ago.

Perhaps it is also about how much control you want or need.

Anyways, just some thoughts.

  1. // Example of assigning event via code. In this scenario I would say it's the same as assigning in the inspector, and may actually cause unwanted behavior if you change the method name.
  2. createButton.onClick.Add (new EventDelegate (this, "OnCreate"));
  4. void OnCreate(){
  5.  // create something
  6. }

This feels more maintainable to me than having to manually assign events via inspector.
  1. // However assigning events like this removes the misspelled string, as now you have to strongly use the actual method
  2. // Setup button events
  3. createButton.onClick.Add(new EventDelegate(OnCreate));
  4. editButton.onClick.Add (new EventDelegate (OnEdit));
  5. exportViewButton.onClick.Add (new EventDelegate (OnExport));
  6. helpButton.onClick.Add (new EventDelegate (OnHelp));
  7. doneButton.onClick.Add (new EventDelegate (OnDone));

And even further, adding events with parameters.

  1. // Sample Event Delegate with parameter: EventDelegate.Set(btn.onClick, delegate() { MyClick(123); });
  2. EventDelegate.Set (newCanvasViewController.canvasOverviewButton.onClick, delegate() {
  3.         OnClickedCanvasOverview (newCanvasViewController);
  4. });
  6. EventDelegate.Set (newCanvasViewController.deleteButton.onClick, delegate() {
  7.         OnDelete (newCanvasViewController);
  8. });
  10. EventDelegate.Set (newCanvasViewController.createButton.onClick, delegate() {
  11.         OnFinishCreate (newCanvasViewController);
  12. });
  14. EventDelegate.Set (newCanvasViewController.titleOfCanvasInput.onSubmit, delegate() {
  15.         OnDone();
  16. });
I am in no way diminishing the importance and awesome-ness, and ease of assigning events via Inspector. I'm simply speculating as a programmer.

NGUI 3 Support / SetDirty(this)
« on: January 16, 2014, 01:04:16 PM »
This line, UnityEditor.EditorUtility.SetDirty(this) is being called from some UILabel object, but I have no idea which one, so I can't tell which UILabel is missing.

This happens when I LoadLevel.AsyncAdditive. Essentially I'm async/additive a scene, and than delete the root of the previous scene.

If I comment out the SetDirty(this) line, things go smoothly and no errors. However, I'm sure that line is there for a reason.
Instead of commenting it out, should I just add a null check?

The Error Message:
  1. MissingReferenceException: The object of type 'UILabel' has been destroyed but you are still trying to access it.
  2. Your script should either check if it is null or you should not destroy the object.
  3. UIWidget.MarkAsChanged () (at Assets/NGUI/Examples/Scripts/Internal/UIWidget.cs:552)
  4. UILabel.MarkAsChanged () (at Assets/NGUI/Examples/Scripts/UI/UILabel.cs:900)
  5. UnityEngine.Font.InvokeFontTextureRebuildCallback_Internal ()
  6. UnityEngine.Font:RequestCharactersInTexture(String, Int32, FontStyle)
  7. NGUIText:WrapText(Font, String, String&) (at Assets/NGUI/Examples/Scripts/Internal/NGUIText.cs:357)
  8. UILabel:ProcessText(Boolean) (at Assets/NGUI/Examples/Scripts/UI/UILabel.cs:950)
  9. UILabel:ProcessText() (at Assets/NGUI/Examples/Scripts/UI/UILabel.cs:907)
  10. UILabel:ProcessAndRequest() (at Assets/NGUI/Examples/Scripts/UI/UILabel.cs:423)
  11. UILabel:set_trueTypeFont(Font) (at Assets/NGUI/Examples/Scripts/UI/UILabel.cs:191)
  12. UILabel:OnValidate() (at Assets/NGUI/Examples/Scripts/UI/UILabel.cs:449)

The Line comes from UIWidget:
  1. public virtual void MarkAsChanged ()
  2.         {
  3.                 mChanged = true;
  5.                                 UnityEditor.EditorUtility.SetDirty(this);
  6. #endif

NGUI 3 Support / Re: Sliced Sprite issues with atlas reference swap
« on: November 14, 2013, 05:06:07 PM »
Ah excellent. I actually had to do "1" for my 320dpi atlas, and "1.5" for my 160dpi atlas.

NGUI 3 Support / Sliced Sprite issues with atlas reference swap
« on: November 14, 2013, 04:20:26 PM »
In my project the expected behavior is correct on Simple Sprites.
The expected behavior when switching between low/hi def atlas is that a) the sprite uses the same real estate, b) the sprite looks low/hi quality.

The issue is with sliced sprites. In the provided images, I have 2 button sprites. One exported at 160dpi, and the other at 320dpi. The result is smaller pixel size, thus less memory and texture space.

I have ensured that both sprites have the same slicing.

The 320dpi button looks perfect. However the 160dpi sprite takes up more real estate than expected and becomes deformed. Rather than the expected behavior of looking lower quality.

Is this the expected behavior for sliced sprites?

I have considered Not using a sliced sprite, which would indeed fix the issue, but there are many areas in the project in which a sliced sprite would be much more efficient over full size exports.



EDIT: I just realized that you may not be able to fully see the size differences with the provided button screenshots because you can't see the full context of the scene. Unfortunately due to the projects NDA, I may run into problems revealing more.

NGUI 3 Support / Re: Atlas Reference breaks when adjusting slice
« on: November 13, 2013, 04:27:18 PM »
One day if we meet, I will shake your hand and say, "Thanks for the hotfix."
Best developer of the year award.

NGUI 3 Support / Fate of NGUI after uGUI
« on: November 13, 2013, 04:22:11 PM »
What is the fate of NGUI after uGUI releases?
NGUI and uGUI are very similar because it's from the same developer, but will there be drastic enough differences to choose one over the other?
Or is it more like those using NGUI will continue to use it in current projects, but in new projects switch to uGUI.

NGUI 3 Support / Re: Atlas Reference breaks when adjusting slice
« on: November 13, 2013, 04:12:19 PM »
Thanks for the quick reply! I look forward to seeing some pull notifications in bitbucket. It's like christmas every time.

NGUI 3 Support / Atlas Reference breaks when adjusting slice
« on: November 13, 2013, 04:03:09 PM »
Hey, I'm using a hi/low def atlas with a reference. I ensure that all my sprites are using the reference. The problem is, if I adjust the slicing of a sprite, the reference breaks and any sprites with the adjusted slice now only refers to the non-reference atlas.

For example, if I have a button with a Background sprite, and its atlas is GUI_Atlas_Reference and that currently points to GUI_Atlas_160, if I adjust the slicing in the GUI_Atlas_160, the background sprite no longer points to GUI_Atlas_Reference, it now points to the last atlas the reference was pointing at, which in this case would be GUI_Atlas_160.

The problem is, because the 2 atlases may require difference slicing for the same sprite, I try to get them close, but I have to keep going back to my gameObject sprite and reattach the GUI_Atlas_Reference.

I could get through this by just ensuring all my slices are done right in the first place, but sometimes it's difficult to adjust the slicing correctly without seeing the end result in the scene.

perhaps this could be resolved in NGUI?


NGUI 3 Support / Colliders automatically reset
« on: October 24, 2013, 11:44:54 AM »
I keep having this odd issue with Colliders. I'm not sure if it's from NGUI or Unity.

Essentially, I'd adjust my colliders for certain UI elements, not in play mode, and they seem to stick for a while, but randomly it seems they readjust as if I had did alt+shft+c to add a collider.

Is there something that causes colliders to auto readjust? How can I prevent this from happening?

-Jacob S.

NGUI 3 Support / Request: Set Selection Depth to 0
« on: September 30, 2013, 02:58:44 PM »
First off, the updated depth system is working perfect for me. Thank you.
My one request is to have the option in NGUI menu to set all the selected widgets Depth to 0. This way I can decide for myself the depths of each widget, but setting them to 0 initially gives me a starting point.


Pages: [1] 2 3