eDriven Q&A

Let me continue with the previous post.

Since the Alert class closes itself (cancels) on KEY_UP, other components shouldn’t react on this event since they are not in focus.

In GUI programming, a number of actions has to be “done later”.

There are convenience methods for delaying actions in eDriven. One of them is the Defer method. This is the instance method of the component. If you have a piece of code that has to be done a few frames later, this is the way you use it:

Defer(delegate { Foo(); }, 1); // Foo() will run one frame later

Normally, delays so short aren’t noticeable.

Ah, you are not inside the component. If deferring from scripts, use:

DeferManager.Instance.Defer(delegate { Foo(); }, 3); // defer for 3 frames

Or, if Foo has the DeferManager.DelayedAction signature (which it has here):

DeferManager.Instance.Defer(Foo, 3); // defer for 3 frames

And inside the Foo is everything you need to run after N frames:

private void Foo() {
    Alert.Show(...)
}

Or directly via delegate:

DeferManager.Instance.Defer(delegate {
    Alert.Show(...)
}, 3); // defer for 3 frames

Of course :slight_smile: To me this happens automatically. Sorry for assuming everybody’s using Visual Studio (Express) or ReSharper. :slight_smile:

I prefer to be concise. Very nice of you for filling in the gaps → fell free to do that :wink:

Nope, as I remember this is where the underlying immediate TextField takes control.

I just implemented the following static properties on Alert:

public static bool CircularTabs;
public static bool CircularArrows;
public static bool ArrowsEnabled = true;

(will go into the next build)

Implement GetTabChildren() as in one of the examples. With it, you can also define the order.

The latter is written OK - it’s all eDriven events (eDriven.Core.Events.Event)

Actually I saw this warning once - in script - and cannot remember the reason. Try using the method reference instead of the delegate.

I’m using Debug.Log() for debugging purposes (got a special debug build with #if DEBUG statements and writing interesting things to log only when in debug build).

You have to chose a single layout for the container, and all of its children play by its rules.
Or: you can turn the layout OFF for some children with: child.IncludeInLayout = false;
Or: you could layer two containers on top of each other, each with a different layout.

Btw. LayoutDescriptors are defaults made for quick prototyping, normally you should use the Layout property instead. Plug in any of the layouts (BoxLayout - this is both HBox and VBox), Absolute layout etc. and configure it in details.

Place the control into a Container (or Stage) that has an AbsoluteLayout. Make it:

myControl.Width = 100;
myControl.Right = 0;

Actually I can, because this is not the framework code, but a specific (script) implementation for my demos (attach).

This is also the MVC example (or as I call it: “semi data-binding”).

1019734–37780–$OptionsToolbar.zip (5.83 KB)

Nah, like it as it is.

Will look at it.

If I could split in 2, one of us would be fixing the Level bug, and the other one would answer your questions :slight_smile:

Didn’t try it, but should work with Change event:

txt.Change += delegate (Event e) {
    txt.Text = txt.Text.ToUpper();
}

No (for individual controls), that would break the layout rules, wouldn’t it? Layout is how the parent places its children, not vice-versa.

The solution for this error is found here. Basically you have to tweak the font importer.

Attach.

1019779–37783–$InspectorDetailsWindow.cs (6.07 KB)

There’s a ScreenSize property in SystemManager which gives you the currrent screen dimensions.

When placing the control inside a container, it won’t be measured as long as the container doesn’t run the measure pass. So, you cannot know the final size except if you give it the fixed size.

However, there’s a method to force validation passes on control which is not yet officially measured: you have to call myControl.ValidateNow() and after that you can read it’s dimensions for further calculations.

Cheers!

This is a sporadic error (I saw it once, for me it works). When it happens, proceed as follows:

Instead of this:

txt.Change += delegate (Event e) {
	txt.Text = txt.Text.ToUpper();
}

write this:

txt.Change += new EventHandler(delegate (Event e) {
	txt.Text = txt.Text.ToUpper();
});

or this:

txt.Change += ChangeHandler;

private void ChangeHandler(Event e) {
	txt.Text = txt.Text.ToUpper();
}

Bugs fixed. Uploading a new version to the AssetStore tonight. Will post a message when visible online (probably tomorrow).

Hey dkozar, are you going to do any examples/tutorial videos for the edriven framework like you have for the GUI? I’m very interested in learning about software development practices outside of unity, and this seems like a great way.

I’d really like to, but never having enough time for eDriven.Core, since promoting GUI :expressionless:

However, there are great resources for figuring out how it works:

  1. GitHub repository: https://github.com/dkozar/eDriven

  2. Sources of eDriven.Gui demos, which also contain Core classes. For example, the Twitter demo shows how to connect asynchronously to a server as well as the usage of other core classes. Source here: http://edrivenunity.com/backend/source/load-images-source/

A small demo I made yesterday (loading different scenes…): http://edrivenunity.com/unity/load_level/

Set this up before any of eDriven managers gets called, for instance:

void Awake()
{
    eDriven.Core.Framework.EnableInfoMessages = false;
}

Try using only 1 default font per project, and let the other be named fonts.

Furthermore you could style each component instance using the same style names a mapper property names, starting with small uppercase letter:

Label lbl = new Label { Text = "Styled label" };
lbl.SetStyle("labelStyle", myGUIStyle);

Will look into it.