State-of-the Art Appearance with PB?

[Charles Pegge]

That's several operating systems, not a control!

For Windows Presentation Foundation, I see several meanings:

1 Foundation as in Cosmetics
2 Foundation as in base of a building
3 Foundation as in Isaac Asimov - Galactic Dominion
4 Foundation as in charitable or philanthropic organisation

I am uncertain as to which of these predominate.

But for more humble aspirations, I think there is much to be said for building controls around OpenGL especially if the application is predominantly graphical. Vector graphics simplify the creation of families of controls in a variety of shapes, scales, textures and colors. You would need to devise your own message handling protocols but one potential advantage is operating system independence.

[Patrice Terrier]

That's several operating systems, not a control!

No, that is a language of the fifth generation, named WinDev XII and it has all i stated.

See it there: http://www.windev.com

About WPF, do not underestimate its impact (this remembers me when i first translated GDIPLUS to PB in 2002).

...

[Theo Gottwald]

Hallo Patrice,

I am looking forward to your cooperation with Paul and (hopefully) Dominic to see a VD for such a framework in PB.
If you people will start a cooperation, the overall success is guaranteed, and while you have to share the success,
the effective result for each of you will be a lot better then if you all do "own-soup bussiness".

PS: This WinDev - thing really looks interesting. But i believe this is one step to high to hope on this for PB.
Actually I don't want more then the others have, the most important subset would be at least Ok.

Edwin, of course you can do anythng using a hammer if you're really good in using a hammer.
But a hammer is not the perfect tool for doing anything.

But you know, if the only tool you have is a hammer all things look like nails to you :-).

[Edwin Knoppert]

The list shown above is not something i would work out with plain code.
The statement it can't be done with PB is just to harsh.
Once you have ActiveX for example, OCX's can be used and thus solves a great deal isn't?
It's not impossible but it maybe to hard or to cumbersome.

No, I am not a fan of OCX since it requires registering.

I am no longer so much against using additionally purchased controls.

[Patrice Terrier]

The statement it can't be done with PB is just to harsh.

If it would take me years-of-work to do it in PB, then i better choose another tool that will let me do it in a snap or in just a few hours work.

We all know that a small development team can't compete in front of hundreds programmers working together.
That's the problem of PB, it will never reach a critic size without the help of an external programming team working aside of it. But then, this would mean a complete change of the PB's policy, and that is another debate.

For myself, i would be glad to contribute on such a project, but i must also earn my living, because i don't have a regular work to feed me

Anyway if a couple of us could work together, i think we could produce something nice (Visual Studio alike), in say one year or perhaps less.

But the problem is, would people leave DDT?
I think yes, if they just have to fill-in the code like in VS, or a tool like WinDev.

...

[Chris Boss]

While its nice to have a lot of high level custom controls, I took a different approach in my GUI engine and designer.

I figured it would be hard to please everyone with custom controls, so I took a slightly lower level approach.

(1) The Custom controls I did add would be of a more low level nature. For example, my Canvas control is used by customers to build their own graphic controls. For example some have used it for building a Charting control, a design layout control, animated controls, etc. Since it is more low level and has a supporting graphic engine users can build what they need and this is almost limitless. With the new alphablending sprite engine and the supporting graphic commands, all sorts of animated controls can be built.

Looking at other peoples controls, I would probably say that Patrices GDImage is the most useful. It could be used to create dozens of amazingly advanced user interfaces.
I think its lower level nature is more useful in the long run. Also Elias' EGrid while a high level control (Grid), is has so many ways to customize it, it really becomes a more low level tool with nearly limitless uses.

(2) Support existing control customization in Windows. My GUI engine has full support for the OwnerDraw feature of Windows. Again this allows users to customize the look and feel of existing controls. Not only is there a low level ownerdraw engine, but even a high level one with a simplified ownerdraw command set. Two of the custom controls in the engine are actually built on top of this low level engine (property listbox control and the files listbox control). The GUI engines 3D/2D colored buttons are also based on this engine. The Visual Designer even supports button plugins so the user can create their own 3D button engine based on the this low level engine.

(3) Region support. Low level support for simple regions (ellipse, reounded rect) as well as higher level support for generating complex regions on the fly (using bitmaps) allow users to customize the shape of both forms and controls. The canvas control and turtle control both can generate a region on the fly to modify the actual shape of the control. Also there is support for polygon based regions using a simplified polygon definition command.

(4) Subclassing engine. Controls are easily subclassed and events generated for common window procedure messages so control actions can be modified.

The idea is, rather than add dozens of custom controls which are high level UI's, add a lot of lower level features so users can customize and build their own. Then the choices are limitless. Also the beauty of creating your own interfaces based on an effecient engine, is that it allows you to add dozens in unique control interfaces with little overhead.

When you see tools for other programming languages with all sorts of custom controls, often times they are simply existing controls (ie. common controls) which have been customized to add a few new features. 

For example, look at the listbox control. Many advanced UI controls are simply a listbox, but the items are drawn differently or may have a few improved user input features (ie. an item is a button which can be clicked to display a dialog or something). Ownerdraw can do all of this! The listbox can be customized in thousands of ways.

Lastly, I think a good number of commercial apps with nice UI's use fancy controls simply as eye candy. They may look fancy, but at times they may not add any real new functionality to the control. The functionality of the controls is what counts and giving the programmer the ability for endless customizations, allows programmers to build far more advanced UI's.

[Paul Squires]

I would be interested in knowing how many PB programmers take the time (or have the design skills) to be able to use ownerdrawn to achieve the functionality of many high level UI elements available on the market (or even create a control from scratch). I surmise that it is only a select few. My gut tells me that most programmers simply want to take an existing GUI package and integrate it into their program. No fuss, no re-inventing the wheel. Much like the old days of Visual Basic where programmers simply bought a 3rd party package from add-on vendors that extended the GUI usefulness via a VBX or OCX.

Take a look at the videos for many of the controls that Theo references at http://www.infragistics.com/dotnet/netadvantage/winforms.aspx  They are more than simple extended versions of the standard Windows controls and I contend that not many PB'ers would go through the trouble of trying to roll their own versions of them.

It is nice to have the functionality available to allow users to create low-level customization of controls (even controls from scratch), but I suggest that for every 1 person who takes advantage of that functionality, there are 10 more who would rather simply 'plug and play' with an existing product.

I would like to believe that all my customers have the time, skill, design ability, and patience to roll their controls but I expect that is not the case. I do know that I constantly get emails from people wondering if I have more advanced GUI elements available (or if I can write one for them). 

Custom controls (VBX, OCX) is what made Visual Basic the #1 programming environment in the world. That must account for something. 

[Paul Squires]

Lastly, I think a good number of commercial apps with nice UI's use fancy controls simply as eye candy. They may look fancy, but at times they may not add any real new functionality to the control.

In some cases I agree with you, but what we think is irrelevant. If Mr. Frank Customer thinks the UI is the deciding factor in his purchase decision than that is what counts - not whether the control consumes 10% more GDI resources or is 100K. He could care less. As much as we hate to admit it, the looks of an application helps to sell it. I have been guilty of this as I'm sure most everyone else here has been as well. If I download a program that looks archaic then (for whatever reason) I may not spend as much time evaluating it as I should. Recently, I went looking for an accounting program - many of them probably all accomplished the end result that I needed, but the ones that stood out were the ones that looked sexier. It's like going to a bar... your eyes gravitate to the good looking girls first (I hope why wife doesn't read this). 

[Edwin Knoppert]

We just got a compiliment about our more or less major webapp for internal use.
(Customer stuff etc)

Personally i think a webinterface is the way to go but since i am a (asp.net) programmer i see there is much to learn to make things right and even to work.
A webinterface is pretty much behaving different from a generic windows app.
At this time a webapp can not be compared imo, technically it's so much more work to let it behave properly.

1) I think users understand a webinterface quicker somehow (speculating)

2) The idea of having centralized applications is a serious favourite for me.

3) As webapp.. I would not never have achieved this without ASP.NET

[Patrice Terrier]

We strongly believe that, from the user's point of view,
your application's appearance is the biggest single factor that can make the difference
between your product and that of your competitors.

You can read it on the WinLIFT's main page since year 1998, and still very accurate

...

[Edwin Knoppert]

You may push it but a tool is not a goal..

[Patrice Terrier]

a tool is not a goal

Right you are, but always better to put a cherry on the cake 

[Frederick J. Harris]

     My comment here might be completely irrelevant but looks/appearance means very close to nothing where I work.  All that matters is simple functionality.  I work for a large goverment forestry agency and all of our operations are heavily computerized. Therefore, my remarks are from what would be catagorized as an industrial setting.

     We manage and harvest timber.  First, the timber needs to be marked/selected for harvest.  Timber sales contain thousands of trees and our trees are valuable enough that they are individually tallied using hand held data recorders.  A lot of code there!  After the tallying is done piles of processing needs to occur to compute volumes, values, timber sale documents, etc.  We have approximately 150 or so sales per year and the sales are sold on contracts running from 1 to 3 years.  We keep track of everything using centralized databases.  Our revenue from timber sales is anywhere from 30 million to 45 million dollars/year.

     For many years (approx 20) a mainframe computer system programmed in Algol did our database processing for our Timber Sale System.  Long about 1997 that system had to be phased out and we needed to come up with another system.  The programmer who created and maintained the mainframe system was an employee of our organization, and that person was in charge of developing the specifications for the new and to be contracted out system.  To make a long and agonizing story short, that new system was in place for about 6 years and we had to abandon it after having sunk in the neighborhood of 5 to 8 million dollars in it.  For the last several years of its existance we paid an annual fee for the software licence of $29,000/year and sustained an annual support cost of around a quarter of a million dollars per year to keep it staggering along.

     The system was so bad that for the last several years of its use we were not even able to output an annual report of our timber sale activities for that year.  Data just simply disappeared like stuff going into a 'black hole'.  Let me just give an example.  Many screens of the application had a 'Submit' button, but they also had the little 'x' in the title bar to also exit the screen.  In many screens, if you exited out by clicking the 'x' button everything you had just entered would be lost without warning or knowledge.  In other cases data might have been successfully written to a file/database, only to be lost or chewed up by poor code somewhere else at indeterminate points in time at a future date.

     Around 2004 I began re-writting the whole system one piece at a time in PowerBASIC.  Somewhere around 2005 or 2006 we started using this system.  It has been highly successful and everybody likes it.  What people like about it is really fundamental in nature, and that is that it simply works.  People know what a plain jane looking button is, and they have learned that when they click the submit button their data will indeed be saved, and that if the system has any difficulties with the data, they will be notified. 

     So we have not had good results with contracting out computer systems.  For the 20 years or so we ran the mainframe system all was well because we had the programmer on staff.  Then there were the bad years of the contracted out failed system.  Now everybody seems happy with my largely PowerBASIC system, and of course I am here to support it.

     I only know about my little world, but from things I have read I have come to understand that many goverments and corporations have huge computer systems that don't always work very well.  These systems aren't bought for $49.95 in a shrink wrapped box at Walmart. Maybe if what you are selling is a $49.95 game, then pretty charcoal colored buttons with rounded edges will make the sale.  But where I work plain old square blue buttons that won't lose track of millions of dollars worth of timber are in high demand.

     Many if not most large endeavors such as where I work use such technologies as .NET for their computer systems.  At the time I began writing our present system I was fooling around with C# and vb.net but I didn't like it.  I was put off by all the types of issues we are all familiar with such as bloat, hard to track down dependencies and installation glitches/problems, reliance on the registry for EVERYTHING, and last but not least my final recognition of the fact that Microsoft could develop/obsolete application development paradigms faster than I could master them.  Whereas with PowerBASIC the infrequency of change that is oftentimes a cause of lament by many is seen as a precious virtue by me.  I'll get off my soap box now!

[Theo Gottwald]

>goverment forestry agency

Fred, shure this is indeed your little world.

If you want to go to the mass-market with a program, you need to think as Patrice wrote it on his WEB-Site.

Even big gouverment agencies like yours will not accept ugly apps if they do not trust the source of these programs.

Thats the same problem like with your gf. If she knows you for several years, its no problem, if you don't go to the hairdresser anymore and always take the old clothes. But if you meet her the first time - and thats what I am talking about - you need to be competitive.

Chris, did I say that I like your EZ-GUI and your programming Philosophy? Mostly for its reliability and stability.

I am testing it in my actual project and when I am done, I'll post a report on my experiences.
Let me say at this place that I am actually very happy with the stability of the results and the ease-of-use of your drag'n drop engine.
As said - whats there is stable and is a good extension for doing some sort of projects more quickly.
But then if we look at the beauty of a really competitive interfaces, and interface-frameworks (all windows in one window - sizable, configurable, moveable), your Tool is of course no sollution to this. The only thing in this direction - easy to use - is the gradient for buttons. A framework or a layout-manager ... this is just away from the scope of EZ-GUI as I see it.

My favourite VD, Phoenix2, is more near to a framework. Using Dominics Layout-Manager and Splitterbars, a project comes a bit more near to this point of beeing a framework.
But then I had resource problems in my Phoenix apps. Two of them do just hang if I have not much system resources left. And the help files got never completed as far as I know.

Why does EZ-GUI miss needed features and Phoenix has no complete help file, why does the Combo box from Firefly didn't work properly on Dual-Screen?

Because its just too much for a single person to do everything. Its a question of self-motivation and a question of success in marketing.
If you all combine your power and make one tool, such mistakes and problems will be problems of the past.

This is where I am at my point. What I see is after all a lot of sollutions which are good in some parts, not only good - even excellent.
But then there are corners with missing features, small or bigger bugs and  just problems that would not be there if at least 2-3 more persons would also work on that project.

I think some of you -Patrice anyway - have understood the point I am trying to make here.

The next Generation of Programming tools for the next generation of PB should have better quality, but then you all should find a way to concentrate your forces. Make common compatible interfaces and Tools.

Don't do like Blue-Ray and HD-DVD to let the customer decide between X and Y. Give them a reason to be stronger by using all your tools.

Or even better: combine your strength and make tools together that will be as good as the competition in the .NET world.

Get new people into Powerbasic.

Most programmer will these days not even take a look into PB, because its still too hard to use,
and the results are just too old fashioned.
Its no easy sollution, to use ownerdraw (like Chris suggest) and develope the wheel new in a world, where everyone else drives a motor bike.

[Chris Boss]

Freds comments have merit.

A lot depends upon the market for the software and how many companies sell similiar software.

Mass market software is often judged by how it looks.

Vertical market software is much, much different!

I developed custom software for a variety of businesses for years, and what counted was functionality.

In such cases, fancy UI controls don't make a difference. It is the overall design of a product and how well it functions for the task at hand.
Eye candy won't make up for program that does not handle a task well.

Too much emphasis if often put on how "pretty" an app looks and not enough on how well it functions.

For example, I converted a DOS app I wrote to windows (16 bit) using VB 1.0.

Rather than completely use a Windows style UI, I emulated the DOS apps look and feel. It hand scrolling screens and stuff, but it look more character based and was keyboard driven rather than mouse driven. The reason was productivity. A true Windows UI was slower and less productive than a character based UI like DOS.

The customer is still using the software after a decade and it still is very functional.

The point is, that functionality, including speed of input, was more important that the true Windows look and feel.


Theo,

You might want to experiment with the form plugins in the designer. There is a plugin in the plugins folder for WinLift.
The source code is:  ezplugfm.bas
The compiled plugin is:  ezplugfm.ez_

change the file extension of the plugin from .ez_ to .ezp

and the designer will see it.

This plugin was for using WinLift visually in the Designer. In test mode the form will be skinned by WinLift.

I had a few problems with the stability of winlift when used from the Designer, so I deactivated the plugin in the shipping version of EZGUI.
I didn't have time to find out what cause the instability. The Designer could use the plugin but after awhile it became unstable and could crash.

If you use the plugin and exit the designer and rerun it again, every so often you may be able to get around this.

The reason I tried to build a plugin for winlift was because I saw the potential of the two tools being integrated into a visual environment.



Paul commented about few using ownerdraw, so it isn't going to be used often.
EZGUI gets around this, because its implimentation of ownerdraw is very, very easy to use.
Also I provided what I call a "Simplified Ownerdraw" command set which allows changing the look of controls with just a few lines of code.

For example to display an ownerdraw combobox which displays color blocks in the items (actual RGB color) is as simple as:

SUB TBAR2_FONTCOLORS_Events( MyID&, CMsg&, CVal&, Cancel&)
     SELECT CASE CMsg&
          CASE %EZ_Change
          CASE %EZ_OwnerDraw
               EZ_DrawComboBox "TBAR2", MyID&, CVal&, 4, 0, "C"
          CASE %EZ_OwnerSize
               EZ_SizeComboBox CVal&, 4
          CASE ELSE
     END SELECT
END SUB

The EZ_DrawComboBox command does all the drawing in the %EZ_OwnerDraw event.

Even beginners can use the simplified ownerdraw command set.