Some improvements

[mgpw4me@yahoo.com]

The fact that skins are designed to be displayed at a specific resolution is a failing in the skin system...

Perhaps is should be a browser system, perhaps it should not—I don't know. But it isn't. And I doubt we can expect the skinning system to be replaced any time soon.

PVD supports XML and hyperlinks...if it walks like a duck...  I think you're being overly dramatic suggesting I want a whole new skinning system.  All I asked for was horizontal information pane scrolling when there is a text overflow (which there are good reasons to discount, but I discount them  ).

I dislike having things squished into the available space (sometimes by truncating ie. single line text fields, sometimes by expanding to extra display lines ie. genres, and sometimes to concatenating lines ie. genres ).  In particular, the truncation of a person's filmography information is very irritating to me, since both the title and original title are truncated equally.  Given that a skin may be altered to provide 'ease of use' features (ie. big fonts), current data hiding methods don't really provide a solution.

It's simple priorities to me.  Is the display format more important than the data itself?  If so, I'm offbase (who could guess a database application might consider it's data of secondary importance?), in which case my suggestion becomes that truncation of displayed data be eliminated (which will require much more code than adding horizontal scrolling).

[buah]

Concatenate two monitors horizontally, et voila!

[rick.ca]

I think you're being overly dramatic suggesting I want a whole new skinning system.

I don't think so. I was responding directly to what you said... "Actually, with more thought, all that's needed to display a skin in a web browser is an XSL file (not exactly true...the xml from PVD isn't really browser compliant...but it's easy enough to fix)." It's obvious your specific complaints could be addressed within the current system, but it seems you'd rather make the point the fundamental nature of the display system should be different.

There are also much simpler solutions if the limitations of the current system are respected. Information truncated in a short text field would not be in a long text or memo field. It shouldn't be necessary to make the skin system adapt to data stored in an inappropriate field type. But I suppose there are exceptions to that rule—the data growing beyond what the field was originally meant for, or users using the field for something different. To accommodate these situations, a skin function that transforms data from one type to another is surely feasible.

As I've mentioned a number of times elsewhere, I hope the ability to display HTML is added at some point. It would be handy for importing and displaying entire pages of data that are already formatted appropriately, displaying actual search result pages, and just providing an embedded browsing capability. I don't know whether such a thing would be a separate window, a skin function for displaying a specified URL in a memo-like HTML field, or both. I imagine doing something like that is going to beg the question, "Why not do the whole display system in HTML?" Like I said, I don't know. I do know I have no use for other movie database software that use that approach. But I don't know if that's because of limitations in the approach, or just crappy implementations.

Concatenate two monitors horizontally, et voila!

I think we're going to pay for having exposed this guy to Monty Python.

[buah]

I think we're going to pay

Nuh, that one was on the house

a skin function that transforms data from one type to another is surely feasible.

I'm not sure I understood this?

[rick.ca]

I'm not sure I understood this?

A skin function that would, for example, display data from a short text field as if it came from a long text field—so it won't be truncated.

[buah]

Oh, ok. For a moment it sounded to me like the data itself to be transformed, from numbers to text, for instance, etc...

[mgpw4me@yahoo.com]

My quote in context is more appropriate.  I was discussing the possibility of creating xml skins from a WYSIWYG development environment.

[nostra]

Relative font sizes in the skins (ie. <font><size>+1</size></font>) would be cool.  TOOLS->PREFERENCES->APPEARANCES would seem a logical place to set a default font size for skins.

The idea is an interesting one, but I think it will be too difficult to make it work good for all skins possible, but maybe I will just implement relative font sizes with static defaults some time.

The fact that skins are designed to be displayed at a specific resolution is a failing in the skin system.  Fixed sizes (pixels or point sizes) means simply that if I have a different monitor setting from the skin designer, the skin doesn't display as it was designed.  It may well be that there is text overflow when fonts are resized, but then, why can't the skin scroll as a web browser does when this occurs?  Vertical scrolling is already implemented, so that's half-way home.

I most cases you can have automatic widths and in all cases the heights are calculated automatically; horizontal scroll bars in separate fields just do not look good enough for implementing and they are in most cases not needed.

I think a concatenate function would be the appropriate tool for this situation—and might otherwise be very useful—but no one has asked for it. Until now. Wink

I'll think about it, but there some problems here: different field types and edit mode...

As I've mentioned a number of times elsewhere, I hope the ability to display HTML is added at some point. It would be handy for importing and displaying entire pages of data that are already formatted appropriately, displaying actual search result pages, and just providing an embedded browsing capability. I don't know whether such a thing would be a separate window, a skin function for displaying a specified URL in a memo-like HTML field, or both. I imagine doing something like that is going to beg the question, "Why not do the whole display system in HTML?" Like I said, I don't know. I do know I have no use for other movie database software that use that approach. But I don't know if that's because of limitations in the approach, or just crappy implementations.

I could embed internet explorer pretty easily for such fields some time later, but I really do not want to use a browser for skinning. As I was programming the very first version of PVD I have considered an embedded browser for information panes as many database apps do, but I quickly found out that too many problems come up and the whole flexibility is lost or even gone at all.

I was discussing the possibility of creating xml skins from a WYSIWYG development environment.

I will be glad if you write such an editor, really

[mgpw4me@yahoo.com]

I will be glad if you write such an editor, really

No need to totally re-invent the wheel...  http://msdn.microsoft.com/en-us/library/ms977865.aspx  ... requires IE to be installed (not necessarily as a primary browser) and there is a check for ie6 in one of the javascript files ... just comment it out if you wish to try the program.

I bumped into this a few days ago.  I didn't really look closely at it, but suppose it could be modified to the skinning model.  I'll look at it this week and decide if it's a reasonable investment of my time.  If not, I'll see what else I can come up.

[rick.ca]

I'll think about it, but there some problems here: different field types and edit mode...

Oh, so that's what mgp meant...

And I want "explode"

...Yes, I suppose edit mode would have to "explode" the concatenation into it's component fields.

As for different field types, you would have to do so arbitrarily based on the input fields (e.g., string + memo -> memo), and probably disallow awkward combinations (e.g., date + list -> ?).

I could embed internet explorer pretty easily for such fields some time later...

How about anything but IE?

[nostra]

How about anything but IE?

IE is the only one that I know for sure that its working good and easy to implement. There should be a possibility to use Mozilla engine as well, but I do not know how difficult it is to embed.

[nostra]

No need to totally re-invent the wheel...  http://msdn.microsoft.com/en-us/library/ms977865.aspx  ... requires IE to be installed (not necessarily as a primary browser) and there is a check for ie6 in one of the javascript files ... just comment it out if you wish to try the program.

Hm, looks promising. I will give it a try on occasion.

[mgpw4me@yahoo.com]

The HTML Delphi control uses the default browser...if I remember correctly.

Note:  The scrolling behavior I was suggesting was for the whole page, not individual fields.  Scrolling the whole screen would be easier to implement that scrolling individual fields, and, as mentioned, multiple scrollbars within the page doesn't look good at all.

[nostra]

he HTML Delphi control uses the default browser...if I remember correctly.

No, it is IE, IMHO

Note:  The scrolling behavior I was suggesting was for the whole page, not individual fields.  Scrolling the whole screen would be easier to implement that scrolling individual fields, and, as mentioned, multiple scrollbars within the page doesn't look good at all.

OK, this changes the story dramatically. I can actually add the suggestion to my TODO List.

[mgpw4me@yahoo.com]

No, it is IE, IMHO

Ooops, right you are.  http://delphi.about.com/b/2005/01/15/using-firefox-instead-of-twebbrowser-in-delphi-applications.htm unfortunately, there would be someone using Opera or Lynx or ... whatever.  Scratch that idea.