Hi Tim

In addition to struggling with the "create new component" process I am also trying to build out a responsive UI for an administrative web application. A good example of such (using Twitter Bootstrap) can be found here:

http://iarouse.com/dist-flatify/v1.3/index.html#/dashboard

EWB has all of the core primitives but lacks the ability to remove form "edges" so that I can't truly "but up" one form against another, for example to have the header section meet the LHS navigation section. I know that can be achieved using simple panels, but this requires the panels to sit on a form and all of my code will reside in a single unit. In reality, I may have 10 or more "views" that I will swap in and out based on user navigation, and the code for each should reside in its own unit, therefore requiring a form.

My EWB1 apps use this technique extensively (albeit with LOTS of maths to handle layouts - no longer necessary) and it works because the forms in question have no "edges". So, how do we remove the edges, or does this come back to my original question about building a new component, based on a TPaperForm, that doesn't have them?

Regards
Mark

Mark Brooks wrote:

> So, how do we remove the edges, or does this come back to my original
> question about building a new component, based on a TPaperForm, that
> doesn't have them?

Sorry, I don't follow this. The TPaperForm looks like it is exactly the
same as the panels in that sample. What is it that you are looking for
that is different?

"Matthew Jones" wrote:

>>Sorry, I don't follow this. The TPaperForm looks like it is exactly the
>>same as the panels in that sample. What is it that you are looking for
>>that is different?

Hi Mathew

If you take a TPaperForm, hide its caption bar and borders, and set its background to a solid fill, say blue, then you'll see that there is still a visible "edge". This stops you "butting" two forms together seamlessly as part of a responsive interface. Make sense?

Mark

Mark Brooks wrote:

> If you take a TPaperForm, hide its caption bar and borders, and set
> its background to a solid fill, say blue, then you'll see that there
> is still a visible "edge". This stops you "butting" two forms
> together seamlessly as part of a responsive interface. Make sense?

So it is the one-pixel border that is the problem. It certainly appears
that this is going to be easily fixed with the alternative interface
feature, or could be done with a different component. The interface has
the borders as a one pixel visible line in the base component.

It does raise the issue of the compromise between the complexity of the
properties and the flexibility of the options.

"Matthew Jones" wrote:

>>So it is the one-pixel border that is the problem. It certainly appears
>>that this is going to be easily fixed with the alternative interface
>>feature, or could be done with a different component. The interface has
>>the borders as a one pixel visible line in the base component.

No. It is not the border. That can be made invisible. There is an "edge" of a few (maybe 5 or 10) pixels thick that exists inside the border and outside of the fill area. Are you not seeing this?

Mark,

it's the base element's padding. Change it in the interface to 0 and it
works. See screenshots.

Uli

Uli Becker wrote:

>>it's the base element's padding. Change it in the interface to 0 and it
>>works. See screenshots.

Got it Uli. Appreciated. So I guess that I'll need to create a new TMegaForm (bad name, but you get what I mean) that does away with the base padding.

Mark,

<<
So I guess that I'll need to create a new TMegaForm (bad name, but you
get what I mean) that does away with the base padding.
>>

If you don't use the padding at all, you can just change the TPaperForm
interface and use it.

I am working on different skins - so I created an additional folder for
each skin, copied the original interfaces and change them.

To recompile the library, I have just to change the search path in the
environment.

Uli

Uli,

<< To recompile the library, I have just to change the search path in the
environment. >>

BTW, the next build has an "automatic rebuild" prompt for this.  If you
change the library search paths, it will ask you if you want to rebuild the
component library when you close the environment options.

Of course, this is just a stop-gap measure.  I'm going to nail down the
interface paths into something more concrete before the final release,
preferably something where you can just select an "interface set" from a
combo box from the main toolbar, and that interface set will have the path
information necessary for the component library build.  IOW, I'll probably
be splitting out the interface paths from the unit search paths in order to
add some clarity to the situation.

Tim Young
Elevate Software
www.elevatesoft.com

Mark,

I think I'm going to need to add separate Client* properties for containers
like panels and forms.  I initially tried to keep these type of
implementation details hidden, and most of the border, background, etc.
properties are for the *client* area, not the base UI element.  But, it
seems like this isn't going to be flexible enough, and it might be necessary
to surface both the client and base UI element properties for borders,
padding, etc.

Tim Young
Elevate Software
www.elevatesoft.com