Updates to SnTW
A few quick answers to some questions...
Don't you have problems with where the layer displays? - I'm sticking to "Auto" at this point for the Notes client. There are some problems if you try to set specific pixel offsets related to subforms. Specifically, if your anchor is in a subform, then when you set pixel locations, they are rendered in design mode relative to the subform. But once that's in a form, they are relative to the ENTIRE FORM. But you can resolve this by simply selecting "Auto" for your top & left controls.
Where'd you get those graphics? - They aren't mine. They were purchased from the fine people at http://www.virtuallnk.com. They have extensive libraries, rendered in 6 different resolutions, in a ton of formats, although I've personally found that the PNGs are the only ones I need. I use Photoshop to manipulate/combine them and save them down to GIFs. (Will Hannover support PNGs? I presume so, since they are surely part of the whole Eclipse model.)
What about printing? - Well, my first answer is that I would never, EVER design a sophisticated system with an concern towards the screen looking like a printed version. Monitors are not pieces of paper, and your mouse is not a pen (well, ok, there are exceptions.) Frankly, I regard printing as a not-all-that-necessary evil, but I'll admit that this is a snobbish attitude from me. Because of that, I'll be doing print-specific versions of these forms. Those versions will have almost nothing whatsoever to do with the versions on the screen.
Does this work in a Browser? - I'm sure you can do similar stuff in a browser. I've done some it before with <DIV> wrapped <IFRAME>s and stuff. I haven't tried using layers for browser rendering. If they work any where near how they do in the Notes client, you could probably do some killer interface work on them. I'm not holding my breath, though. Any attempt to do something like this should be client-side AJAX driven, and I imagine that the hide-when/field-update approach would force server communication, which would be gruesome.
I have to shift gears and get another part of the system done right now, but next week I have something clever planned. I'm going to try out my view/editor combination approach using layers. There's a nice Lotuscript technique I've discovered (others probably know it, too) that will allow me to hide/reveal elements in a parent container document from an event inside an embedded element. That will let me put a further z-axis on my preview pane from those embedded views. It should look pretty slick.
But you'll have to tune in next week for that.
Comments
I've found that pixel placement of layers on its own is only useful for something like a header (put the common header elements/layers on a subform).
For layer placement elsewhere, pixels can be a useful offset within a nested layer structure. In all cases, layer pixels are counted from the container's boundary. For nested layers, the container boundary is the corresponding "parent layer".
Sounds like a lot of trouble perhaps, but it really opens up a few layout options. Particularly when compensating for some strange N6.5 bugs (put a layer on a nested table...and hide-whens in the table may not work; or put a layer on a table inside a tabbed table...the layer isn't exactly displayed when expected). A workaround to both problems/bugs was to auto-top a parent layer outside the table, and then nest a layer inside that, with a top position offset in pixels (or ems or inches or whatever). Note that the offset can be negative...
Anyway, hope that made sense... Somewhat difficult to explain without screenshots (at least that's my excuse).
Looking forward to next week. You're such a tease.
Posted by Rod Stauffer At 02:44:27 AM On 06/16/2006 |