Screenshots requested

[Tom]

Some more.

[Tom]

Two more.

[sdenjupol148]

Tom,

Excellent!

Bobby

[rdonnay]

Tom -

Not only are you a great programmer but you are also a great artist.
I told you the last time I saw you in Germany that you are a "Renaissance Man".
I look forward to seeing you again.

I hope you are willing to show some of your code at our conference.

Roger

[Tom]

Thanks for the compliments.

My code is somehow very ... special. Most of this is done using subclassing and ownerdrawing. The main problem is to access the data inside the drawing routines, since the UI thread, where the drawing happens, works independent from the thread where the logic resides. Everything else is just a little playing around with GRA stuff - painting boxes and circles, loading icons and writing textes. The biggest thing is what you see in screen2.jpg. This is a monster. There are seven ways of drag&drop inside this one, cell marking, statistics and much more. It's highly customizable and looks different at each customer's site.

The calendar you see in two screenshots only resides on a static, which is an empty text static, nothing more. This control can be calibrated, showing the whole day or only one hour, as you want (Shift-Mousewheel). It can show a day, a week or any period you want. Dates can be extended or shortened, just by picking the border and moving it. Several dates can be picked at once and shifted together, like if you want to move all dates half an hour ahead. And so one. I played around with several tools for this, but no one of those was able to do what we want there.

Much work in this. Eight screenshots of some hundreds I could show.

I can't await to see you in Boise!

[skiman]

Tom,

This looks great. Ownerdrawing is the way to go, that's confirmed and proved by your screenshots.

[Tom]

Hi, Chris.

Ownerdrawing is the way to go

In some situations, not in all. A browse with heavy ownerdrawing in it is exclusively used for data represenation, but it can't be used to manipulate the data anymore, like if you have an edit-browse where you're able to doubleclick and just enter data. Those things must be done in nested/hidden controls or in different dialogs. The ownerdrawing routines must reflect the screen resolution, DPI-settings and even the SCALEFACTOR from eXpress++ (which is a great feature!), since fonts, icons and other objects are created and used in there. All dialogs should look the same with all possible settings. Resizing columns changes everything - you can't place a 48x48-icon in a column which only has 20 pixels of width, so it must be recognized in the drawing methods. In the planning system (screen2.jpg), resizing one daily column causes all others to resize aswell, and if this happens, some recalculation is to be done.

I just played a little with 2.0, which provides new features based on HTML and CSS. I didn't come to that point yet, and I can't imagine it's possible to do what I'm currently doing with that, but it maybe a good step to improve application design without digging in the GRA-dirt. Besides, some GRA-functions have little bugs, like GraPathClip() or even a GraBox() with rounded corners - sometimes.

[rdonnay]

I just played a little with 2.0, which provides new features based on HTML and CSS.

What in particular did you play with? I tried XbpHtmlStyle(). It didn't help much and has some bugs.
I couldn't get it to work with XbpStatic() at all. I thought that if I could do that, then I could apply it to the dataArea of the XbpColumn() class because it inherits from XbpStatic().

[bobvolz]

Thomas's screen shots are amazing. Showing you mine would be like comparing the kids drawings that we hung on the refrigerator to a Michealangelo.

See ya in Boise.

[bwolfsohn]

Thomas's screen shots are amazing. Showing you mine would be like comparing the kids drawings that we hung on the refrigerator to a Michealangelo.

See ya in Boise.

and bob's screens probably make mine look pretty...