Quick Comment

[BruceN]

Roger:

I had to do some work on our main sales screen which was done years ago in native xbase, before we came across your express library. This is the first time I've had to work 'native'.

I can't tell you how much easier working with express is. With my limted knowedge it took me about a day to make minor changes that in express I could have done in about an hour or 2!

I hope I NEVER have to work in native xbase again. I thank you for making express so easy for a novice to use!

bruce

[omni]

10-4 on that. I am sure all agree.

Fred
Omni

[rdonnay]

Bruce -

Thanks for your comments.

One of the main reasons I developed the eXpress++ concept was to create a system of code that was easy to maintain and evolve.

Clipper developers were introduced to the term "living application" at the Nantucket Devcons, but the tools available to create such a thing were not very good at the time. We have come a long way since then and I feel confident that eXpress++ and Xbase++ help to realize that dream.

I have always been a fan of well-abstracted systems, but the big disadvantage of code abstraction is that it is often very difficult to understand what the application does by simply looking at the code, or (in the case of data-driven systems) the metadata.

Visual tools and rad tools may help in development but they don't work well when it is necessary make major changes or to tie disparate code structures together.

I work on a lot of third-party code and, I agree, it can be very cumbersome to maintain or evolve.

My greatest satisfaction comes from adding features that allows an existing eXpress++ application to get some great new functionality or a new look, such as the PushButton config system, resizing system, drag-drop system and the scaling system. This gives the app new life with very few code changes.

Soon I will be applying new ideas to the browse system (thanks to Jack Djuif). He did much of the work.

Roger

[bwolfsohn]

10-4 on that. I am sure all agree.

Fred
Omni

Where the hell is that "like" button ??

[Tom]

I use eXpress++ for more than thirteen years now, if I count correctly. I learned a lot about object orientated programming in the meantime (most of it from Roger), I created lots of classes, GUI elements and stuff, improved my database programming and knowledge about codeblock logics, pre-processing, multi-dim-arrays, components and so on. My apps look really great, much better than most competitive apps on the market - even if the competitors have huge teams working on their software.

I could have done all this in plain Xbase++. But my product would not look the same.
To be honest, without eXpress++, my company would not exist anymore.

Thanks a lot, Roger!

[BruceN]

I'm glad to know (and I certainly expected it to be this way) that I'm not the only one who has HUGELY benefitted from Roger's work.

Tom (and other):

Which features (button styles, etc) do you find make the best 'eye candy'? While totally rock solid, versatile, and easy to use, our POS application DEFINATELY looks dated - which has an affect on sales (or the lack thereof). I'd like to spruce it up a bit for the next release - wihout a major re-write.

Suggestions? thanks.

[Tom]

Hi, Bruce.

1. Use visual styles and manifests.
2. Use ownerdrawing within browses to show cells containing lot more information, icons, mixed contenses and so on. Do it with the "subclass" clause of DCBROWSE. You can do almost everything with this - it's unlimited! (They only thing I didn't get to work are mixed row heights.)
3. Use proportional fonts in gets. Remove "typewriter" fonts everywhere. This looks crappy and old-fashioned.
4. Sort your dialogs. Remove button collections or buttons with bitmap captions simulating text+images. Clean up your app. Just show the functions needed often, put the others into menus or elsewhere. Less is more.
5. Use ownerdrawing with other parts like comboboxes. It's quite easy to show combos with text, icons, different colors and GRA elements in every line.
6. Remove "radiobutton collections" and replace them with combos.
7. Add status bars with progress bars and status textes on it. Remove "DC_WaitOn" or equivalent dialogs which pop up to show progresses. Show all this in one dialog!
8. Collect windows. This is bullshit, in statistics for example: Options dialog -> result in a table -> other result as graphics, three or more windows, another one for printing progress. Put this all together in one window. Use hidden statics to switch information in just one window. Reduce the number of windows!
9. Add skins if wanted. (This will create problems with Vista/7, so don't use it there. Give it as an option.)
10. Create a consistent application design. Make your dialogs look similar everywhere.
11. Make your app data-driven. Allow to add or remove fields and dialog elements.
12. Play around with browse presentations.
13. Add icons and replace information like "yes" and "no" (or similar) with them.
14. Show (additional) dialog titles (if needed inside the dialog) with bigger fonts and on gradient backgrounds. Use status bars for this.

t.b.c.

(Most important: Switch to SL1 if not already done.)

[BruceN]

Tom:

Thanks. But I don't understand half of what yuo were talknig about. I am on sl-1. I've used the manifest files and they improve looks on xp, but gave probs on win7/vista so I stopped using them (I know, 7 is really vista sp2).

What are: visual styles, ownerdrawing? I've seen the terms before in posts here, but don't know anything about them. If there are some SIMPLE samples I can lok at to see what they are/do it would be helpful as most of my programming is of the block/copy/modify method due to a lack of comprehension of fundamentals.

thanks,

bruce

[BruceN]

Does anyone have some 'pretty' buttons that I can use to replace the generic Yes, No, Ok, cancel, or other common buttons, etc?

[rdonnay]

Does anyone have some 'pretty' buttons that I can use to replace the generic Yes, No, Ok, cancel, or other common buttons, etc?

Give me a small sample program and I will "pretty it up" for you.