newB - Window control questions...

[esc_oblivion]

Hi,

First off, I'm a new Laszlo devotee - fresh off the Flex slaughter block - and obviously not remotely close to understanding Laszlo completely. As such I appreciate everyone's assistance with my following (potentially "stupid") questions:

1) Pre-created Window Component. It seems to me that it should be possible to control this component outside of it's default operation. I.e. I have a nice screen-layout created, but I want all the windows to be IN-FOCUS, and NON-MOVEABLE (call me a control freak). I went through the documentation last night and didn't see anything that looked to offer that sort of functionality. This question is extremely important to me since even if I created my own Window components then I'd still be using default behavior that doesn't fulfill my needs, right?


2) This question is pretty much tied to question 1. How can behaviors be controlled if by default they don't offer the functionality I require? I.e. I want all windows to be infocus all the time, etc.

Keep in mind when answering my questions that I'm only a few short steps up from infantile understanding, so I need it pretty dumbed down. : -)

Thanks!

- Abe

[antun]

Welcome to Laszlo!

What you've got to understand is that the default Laszlo window is written entirely in LZX. You can see the source code for it here:

http://www.laszlosystems.com/lps/lz-utils/viewer/viewer.jsp?file=/WEB-INF/lps/components/lz/window.lzx

When it comes to customizing behaviors beyond the default options, you've got three approaches:

1) Subclass the window and add behaviors that you need (or just add them to the instance of the window). For example you might add a method that gets called on a key combo to move the window. This is good if you want to add small features. You might also be able to overwrite default methods in the window to remove some features (for example focus behavior). I haven't looked at removing the window's one-focus at a time feature, so I'm not 100% sure that this would be the easiest way to do this.

2) Make a copy of all of the window code, rename it and tweak what you need. This might be practical in cases where you want most of window's features, but it's not practical to use method 1 above.

3) Write your own window. Check out the window tutorial here:

http://www.laszlosystems.com/developers/learn/documentation/tutorials/window.php

I believe (again, I'm not 100% sure) that a lot of the problem-solving that went into developing the default window class was tied to focus behavior, so if don't want your windows to focus at all (remain focused all the time) then this might be the best option for you.

-Antun

[metasarah]

Hi,

I wrote the window classes. I almost put in a flag to make windows not moveable, but decided against it. Is it really a window if it can't be moved? Do you really want the same "look" for something with a different "feel"? It's your app, so I'll let you decide.

I took a quick look to see how you would override the focus and moveable behavior. The base components don't use "onmouseup" and "onmousedown" specifically so you can override those behaviors. (In Laszlo, you can override named methods, not events which create anonymous methods by default.) Look at the "basewindow" calls which has methods: "_mousedown" and "_mouseup". (The "_" indicates that this is intended as private or protected. Its just a naming convention, since Javascript doesn't enforce those notions.)

In a subclass (or instance) of window, you can define those two methods to do nothing, then the window won't be draggable.

To make the window always focused. You'll want to set the attribute 'haswindowfocus' to true and override the '_setwindowfocus' method so that it always just sets the attribute, instead of affecting the focus of its sibling.

Alternately, you could just write your own class that uses the window resources, since it seems you don't need much of the behavior.

I hope that helps. Please let us know if you have further questions.

Sarah

[esc_oblivion]

I like what both of you had to say.

I would make the case for a window being (from a user perspective) more like a frame, but more segmented and capable then HTML frames are.

I have an application I'm designing with - currently - six or so windows/sections. All of them will have innards that are user interactivable (not a word but I think it makes sense in this case), so I become concerned about allowing all six of the windows to be moveable (i.e. float). It's just an invitation for disaster if a user gets carried away moving the windows all over the place and then can't find the window they want or becomes frustrated by the disaster they created.

The moveable ability is very nice to have available, but I will definitely choose one of the methods you suggest, Sarah, in order to exert greater control over my windows.

Of course, I realize that there is room in my design for providing a "reset" button for returning all windows to their initial positions; and I could make a button associated with each window that would retain a specific location (i.e. at the bottom of the pageframe) so that if they arranged all their windows "to their liking" then a simple click on one of those buttons would bring that window to the forefront... but those choices seem like workarounds to me rather than features. I may build in a feature so that individual users can use a preferences menu or somesuch to define their own layout, decide which windows are moveable, closeable, etc.... I like that idea. The ability to customize the user experience based upon their unique preferences I think is very powerful; but as UI designers we have to consider the disasters users can get themselves into and design for the lowest common denominator...

Sarah, your suggestions made sense, and I'll look into which method I prefer. Thanks for the info!

[metasarah]

Have you seen the dashboard demo (http://www.laszlosystems.com/lps/sample-apps/dashboard/dashboard.lzo?lzt=html)?

That demo pre-dates the window component, so the code is going to be different from what I described, but it may be useful to get a feel for an alternate window manager approach.

It shows a concept of a window manager like one that you describe. The user can move windows and then there is a control which sends them back to their original spot.

Good luck with your app!

Sarah