I've been struggling with IMGUI (Legacy and Editor GUI system) a lot.
Problem is I cannot get my head around this Instant way and all the different events.
I built a simple example to demonstrate one of the many frustration I'm having with this system.
bool toggleValue;
void OnGUI()
{
if (toggleValue = GUILayout.Toggle(toggleValue, "Toggle"))
{
EditorGUILayout.LabelField("This is a label");
}
}
Alright, so, in this very simple code, I have a native toggle that shows or not a label depending on it's state. This works perfectly.
Now, I'm writing a piece myself.
bool toggleValue;
void OnGUI()
{
if (toggleValue = Toggle(toggleValue, "Toggle"))
{
EditorGUILayout.LabelField("This is a label");
}
}
bool Toggle(bool state, string label)
{
GUILayout.Label(label, state ? EditorStyles.boldLabel : GUIStyle.none);
if (Event.current.type == EventType.MouseDown && Event.current.button == 0 && GUILayoutUtility.GetLastRect().Contains(Event.current.mousePosition))
return !state;
return state;
}
My goal with this one is to manually reproduce the behaviour of a toggle: My clickable label is bold when active and normal when disable. Similarly to the checkbox graphic of the native toggle. Then, if I catch a click on it's rect, I return the opposite of the state.
In my head, this is suppose to work. However, I'm aware that there's a lot going on with the OnGUI function like the events Repaint and Layout for which the layout needs to be consistent during a frame. Here the error is
ArgumentException: Getting control 1's position in a group with only 1 controls when doing MouseDown
but often also errors like this one
ArgumentException: GUILayout: Mismatched LayoutGroup.MouseDown
I know that these errors are when you change the content between Layout and Repaint. However I cannot find a fix for my simple control. So here is my question.
With the same arguments given to my function Toggle, what do I need to take care of so the toggle works?
I feel like if I have the answer to this, I might be able to understand the key to this system.
Thank you very much
Oh my god I can't believe it. The ONLY thing I was missing was
Event.current.Use();
When the control is clicked.
That's all! Nothing about the layout being changed between Layout and Repaint or anything of the sort.
So if you've got the same problem, just consume the event when it succeeded.
Does anyone know a source for an overview of the Caliburn.Micro Screen/Conductor Lifecycle? For example a sequence diagram / flow chart that describes their call order/dependencies and the conditions when they get called or not?
Until now I have primarily uses OnViewLoaded but I want to know which are called a second time (when shown again) etc. I didn't found a good documentation about the Screen Lifecycle yet.
And yes, I know it is Open Source and I can read the source code or debug that (what I'm doing at the moment)... just thought that this requirement is somewhat basic to work with Caliburn.Micro and there must be something already done and I don't need to create that overview on my own. Maybe the answer might help someone else, too. ;-)
For example, when derriving from Conductor.Collection.OneActive
there are the following (and even more) methods that seem to play a role in the lifecycle and can be overloaded:
protected virtual void OnInitialize()
protected virtual void OnActivate()
protected virtual void OnActivationProcessed(IScreen item, bool success)
protected virtual void OnDeactivate(bool close)
protected virtual void OnViewAttached(object view, object context)
protected virtual void OnViewLoaded(object view)
protected virtual void OnViewReady(object view)
What I have seen so far this seems to be the order (app startup to exit):
OnViewAttached
OnInitialize
OnActivate
OnViewReady
OnViewLoaded
OnActivationProcessed
OnDeactivate
But what are the bullet points for each method? E.g. when is the datacontext set, the style template applied to the view and ready to be shown? When is the view shown? (difference between ViewReady and ViewLoaded?)
Not a full answer but it is a start, from the documentation of this project, which is worth reading, you can find bullet points for some of those events:
OnInitialize – Override this method to add logic which should execute only the first time that the screen is activated. After initialization is complete, IsInitialized will be true.
OnActivate – Override this method to add logic which should execute every time the screen is activated. After activation is complete, IsActive will be true.
OnDeactivate – Override this method to add custom logic which should be executed whenever the screen is deactivated or closed. The bool property will indicated if the deactivation is actually a close. After deactivation is complete, IsActive will be false.
OnViewLoaded – Since Screen implements IViewAware, it takes this as an opportunity to let you know when your view’s Loaded event is fired. Use this if you are following a SupervisingController or PassiveView style and you need to work with the view. This is also a place to put view model logic which may be dependent on the presence of a view even though you may not be working with the view directly.
There is also a good explanation on the parameters being sent to the methods, and many other topics for the layers of the screens and their life cycle.
I have a custom user control which consists of nothing more than an image of an artificial horizon. I want to move it up and down. When there was part of the main form I was able to constantly update the location using the form.OnPaint method. Now that I've moved the image to a separate class the UserControl.OnPaint method is only called when I do things like move the frame.
What's the best way to update the location of the image with each new value? Right now I'm doing something like this...
public void setPitchAngle(double pitchAngle)
{
PitchAngle = pitchAngle;
this.Invalidate();
//this.Update();
}
This works but I'm not sure whether or not this is the right way. The call to update doesn't work because its called from a thread other than the creating thread but I know how to fix that if it also needs to be called.
I have a full screen WPF application built for a touch monitor, and I have some Listboxs on the main screen.
When I flick the 'Listbox' it scrolls fine, but when it gets to the end of the list, the entire application gets pulled down from the top of the screen, can I stop this behavior somehow?
Has anyone else seen this?
Yes, that default behaviour of the ListBox (or rather, the ScrollViewer inside the default ListBox template) is weird - when I first came across it, I thought it must be a practical joke. In fact, it's really hard to find any documentation about it - but it is briefly mentioned here:
The ManipulationBoundaryFeedback event enables applications or components to provide visual feedback when an object hits a boundary. For example, the Window class handles the ManipulationBoundaryFeedback event to cause the window to slightly move when its edge is encountered.
So, a way around it is to handle ManipulationBoundaryFeedback on the ListBox, and set Handled to true:
<ListBox ManipulationBoundaryFeedback="OnManipulationBoundaryFeedback">
// ...
</ListBox>
Code-behind:
private void OnManipulationBoundaryFeedback(object sender, ManipulationBoundaryFeedbackEventArgs e)
{
e.Handled = true;
}
My question is simple: how bad is the following snippet of code? How would you do it?
CancelEventHandler _windowClosing;
private CancelEventHandler WindowClosing
{
set
{
clearEventHandlerList();
this.Closing += value;
_windowClosing = value;
/*
* if calling the method with null parameters,
* it will set up itself as the primary control on the Window
*/
_windowClosing(null,null);
}
get
{
return _windowClosing;
}
}
private readonly CancelEventHandler[] CONTROLS = null;
private int current = 0;
public InitializerForm()
{
InitializeComponent();
/*
* these are the handlers for the different controls,
* in the order of appereance to the user
*/
STATES = new CancelEventHandler[] { handler1, handler2, etc. };
WindowClosing = CONTROLS[0];
}
private void clearEventHandlerList()
{
foreach (CancelEventHandler c in CONTROLS)
{
this.Closing -= c;
}
}
private void handler1(object obj, CancelEventArgs e)
{
if (obj == null)
{
//hide every other control, but this one, also set up if necessary
}
else
{
//do something
WindowClosing = CONTROLS[++current]; // set the next control to show
e.Cancel = true;
}
}
The point would be that the code wouldn't close a form, but instead show another component on it, and the set the way to handle that (this is mobile platform, so clicking OK button on the top generates a closing event). This is because showing several forms (4 or 5) one after another to the user makes the app blink, and also very annoying, while replacing just components is much smoother. This model works, but seems very nasty, and I would like a cleaner way to handle this.
Update:
I updated the code sample so that variable names are somewhat speaky. Still, I'm convinced this is awful, (a) but not sure how much, and more importantly, (b) how to do it better.
Update 2:
So, it seems that the code is still a bit mysterious.
Now here's what the problem is:
I show the user a form, which instructs him what to do in several languages. He proceeds by clicking OK on the window. Next, I ask for his language, and then a few questions (where his/her GPS is, etc.) like this. After he could answer the questions (this shouldn't take more than a few seconds each), I show him a splash screen (I load stuff in a separate thread meanwhile), which has a picture. Showing these forms one after another makes the whole application start slow, and filled with UI lags.
Here's what I do to work around the lags: I put the content of the windows into panels, and put those panels one on another, and hide every one of them but the one that should be visible to the user. (current variable) Each of the windows does different things, so I need to change handler of the window closing event in addition. In this code the part which enables the panel is in the same function (handler1, handler2, etc.) with the part which handles the window closing event. If the arguments are null, it does the former, if it isn't (that means it was triggered by the user) it does the latter.
I need an extensible solution to this so that I can insert and remove dialogs anytime I want (the order and the pointers to the functions are stored in the CONTROLS field, and this seems to be very convenient, if you actually understand it. Although it is never easy to change the entire content of a form, there ought to be a simpler way to do this, as well a nicer one, that is what I'm looking for.
I hope this time I could explain how the model works.
I think it might be theoretically possible to make that code more delightfully diverting, perilously puckish, jovially jeopardous, cheerily chancy and unwarily whimsical but it would require some serious thought.
somehow your code makes me want to cry, i´m sorry. i read it twice and all i know about it is that it "doesStuff" with "STATES".
if you really want some help on this one you will have to work on it yourself first...
Use, XML! It's human-readable!
More seriously-
It seems like you're trying to create some sort of configuration wizard, so I'd start by researching that. Regarding your particular solution, I generally advocate very strongly against the "layered panel" approach. I do so because I maintain apps written by people who found this approach, or the related "hidden tabs on a tab control" approach, to be a good idea. It's not, and maintainers will curse your name for years to come.
That being said, what alternatives are there? Well, one alternative is what you've already dismissed because of its "flicker". I'd say that, in general, the flicker isn't that big of a deal for a quick and dirty application. It might be a good idea to make sure that your new window is called up before closing the old one, for example. (I'm assuming this is possible, I haven't developed on a mobile device.)
Another possibility might be a less-evil version of your layered panels. Instead of throwing a half-dozen panels into one form, create a separate user control for each wizard page and then add/remove the user controls to a containing form. This can avoid your flicker and will prove to be much easier to maintain because each page is in a different control. This might also ease any subsequent "Back" button functionality and make your data structures more naturally defined because those user controls will be associated with a specific logical bit of data. It's still not ideal, but it's probably good enough for a one-off solution.
A third technique, if you foresee extensive wizard modification as the product matures, might be to generalize the creation of your user controls by defining them in a more logical/declarative manner (e.g. via XML). If you dynamically generate sensible controls based on XML, then modifying the panels might be as easy as diving into your XML and doing something like:
<Questions>
<Question type="Text"> <!-- generate a textbox for the answer field -->
Favorite Color:
</Question>
<Question type="Number" range="0-255"> <!-- Maybe this is a spinner -->
The answer to life, the universe, and everything:
</Question>
</Questions>
That's just off the top of my head, and completely overkill for any one-off application, but it's a possibility.
Now, let me caveat this by saying this might work, but it may not be the answer to your real problem - that of a slow and unresponsive UI when you have a lot of forms. The real answer may be to just go ahead and do all separate forms, but have each form load its child forms in a background thread while the user is staring at the first form.
But assuming you're still set on this, I'd start off by making a separate class just to handle the Panel stacking/hierarchy. Call it PanelManager. You would instantiate the PanelManager and associate it with the main form, then add Panels to it (perhaps keyed to a String) and set the order. In the main form, have the closing handler call PanelManager.CloseCurrentPanel() and if there are no more Panels to show then it's time to close the main form.
Time for pseudo-code! Here's a quick idea for the class, i'll leave it to you to implement it:
public class PanelManager {
// constructor
public PanelManager (Form ownerForm);
// short-cut properties
public Panel this[int idx]
{ get; set; }
public int Index
{ get; set; }
// main functionality
public int AddPanel (Panel p);
public void SetPanelOrder (Panel p, int idx);
public void RemovePanel (Panel p);
public void RemovePanelAt (int idx);
// shows the first Panel
public void Show ();
// shows Panel[idx]
public void Show (int idx);
// adds the panel to the top of the stack and displays it
// returns the index of the panel
public int AddPanelAndShow (Panel p);
// hides the current panel, displays the one underneath it
// returns false if there are no more panels
public bool HideCurrentPanel ();
}
in the constructor for the main form, instantiate it by new PanelManager (this), then in the closing event handler, call panelManager.HideCurrentPanel () and then figure out whether or not you need to close it after that.