Here is a list of controls I'd like to use with Powerbasic.
I doubt any of the actual Visual Designer Makers can compete with such good looking stuff.
http://www.infragistics.com/hot/vs2008/quick-comparison-winforms-vs2008.aspx#WindowsFormsQuickComparison
Maybe they'd have to make together ONE product (or use a common interface) which would be competitive at the end instead of "each one baking his own bread" (and reinventing the wheel) ??
If I compare the look and style of these state of the art control, the possibilities of native PB really look a bit old fashioned. What do you think ...?
Creating good controls is not a simple task.
I ever liked to do it very much but once ready they may appear somewhat obsolete.
Especially after Windows95 controls became different.
For example the 'Software' dialog in Windows where an item is an interactive panel.
There are also people liking the Office Ribbon control, well me ~50%, and therefore not really a goal.
Imo complexity is in Grid's and presentation controls.
Grids need to do much more as before, nearly undoable for a single person to invent and maintain updates.
I also think the future is more in flash-control kind of behaviour.
Btw, it is possible to run .NET controls in PB but they would rely on .NET framework of course.
There are .NET controls PwrDev for example can use, controls like a datanavigator icw a grid is more difficult or currently not working.
Not sure what the reason is since i did not investigate that.
Never tested a custom control.
I wish that I could spend my time writing custom controls. I can bang them out it 1% of the time it is taking me to write the Visual Designer! :) Personally, I find writing custom controls to be relatively easy and I use several of them in the new FireFly.
Seriously though, there does not seem to be a big appeal from PB'ers for custom controls (other than for grids). Am I wrong about this? Not sure. Look at Patrice's work - hell, that guy produces incredibly phenomenal graphic controls but I don't see 10 page posts in the PB forums about it. That's a real shame. SIGrid seems to have disappeared, Elias still has a strong grid product, and James Klutho's grid has potential.
Your idea of banding together multiple visual designer creators to form a 'partnership' sounds good in theory but I wonder how it would work in practice? The thought has crossed my mind a few times especially these days where I just don't seem to be getting as much programming done as I would like! :D The thought of tapping into Edwin's and Dominic's brains is really exciting.
>The thought of tapping into Edwin's and Dominic's brains is really exciting.
Stay out of my brain, you'll get damaged!
:) :)
1) I don't think you can make serious sellings by making things for PB users.
Forums like PureBasic confuse(d) me, while the attention is very high, they seem to be even more hobbiest than found on the PB forum.
2) farpoint (spread) wrote activex controls and now .NET controls, i suspect this is (still) the major selling point.
Create something very solid for those techniques and it seems you can make a living from it.
(For some of them at least)
3) PB being better in number crunching and such does not seem to appeal the majority, our mistake that we find it a better tool isn't?
I still think the good thing about PB is that it just does as expected.
I write a SUB to do Job A.
Te Subroutine does exactly Job A.
This alone is something didn't work for me when i tried Purebasic some years ago (still have the licence).
Now I am looking into the Bugs Forum from time to time, hoping, but not realy sure if a switch would be a good idea in terms of reliability for my programs.
While it is true, that there are a few good ideas out there (Patrice etc.), as said, still all PB Developers (each one of these is very talented in programming) cooks his own soup. And thats not going to make any of them or PB as a System really successfull.
As a result, PB Aps are hard to sell because they just look old fashioned.
Yes I could try to use these .NET Stuff from PB - but I doubt it will be as easy as it would be from VS 2008.
The Pharao knew one thing and that was: "SHARE and WIN".
He knew, ALONE - he was nothing.
He needed to share his wealth with all those people around him to be the big king of egypt.
I expect that the combined power of some of those (YOU?) talented programmers could make something, that would really make a visible difference. And therefore be an argument for buying and using Powerbasic. Getting new customers.
If I actually make a PB Programm with those standard controls, it will be really small and work very reliable.
But then if i GO OUT today and look for distributor, they'll kick me out. Because they take a look on the App and say "Sorry this thing looks like its 5 years old. Did you ever see Windows Vista or even XP?".
So IF I as a programmer cannot easily sell my stuff, I have no big interest in buying the underlying Software. Unless I am doing mostly background stuff like DLL's for example. Maybe these things are the things mostly done in PB.
But then ... most of these Visual Designers don't make themselve a market. Then we need "DLL-Konstruktion Kits", "Tool-Collections" or like this.
I think, PB will need new clothes to be competitive in a future. Of course I'd like to see this without the .NET Framework and without paying >$1000 (the price of those controls I linked before). But IF you want to make really professional software for the actual market, you won't have much success without a competitive "dressed" GUI.
Nobody would apply for a new Job in 5 Year old clothes, but this is what PB Apps do - like they look - on the actual Software market.
Hi Theo,
I think Patrices skinning system rocks, and definitely looks "next-gen" enough.
I am very curious about PB9, if it will be next in row release or some noticeable change.
From my experience most lot of users get scared of not standard controls.
Bye,
Petr
All my commercial applications are written in PowerBASIC and they are all skinned window.
Here is an example of what I have done with PB and my WinLIFT SkinEngine almost 16 years ago!
(http://www.zapsolution.com/zfree.jpg)
Thus, i would say the problem is not realy with the capabilities of the language being used, but the capabilities of the programmer using it, and the efforts he puts to learn how Windows itself works.
One of my first invest after buying Charles Petzold 'Windows programming" book, was to buy the MSDN CD-ROM (now DVD-ROM). Without learning how to use the low level API i would haven't been able to write WinLIFT.
The problem i see with PB, is that most programmers do not want to make the effort to learn "real" windows programming, mostly because they have preconcieved opinion about the low level Windows SDK.
And there are several reason for this.
Do you remember the PB slogan about DDT: "DDT kills windows bug dead"...
- Indeed DDT offers just is a limited subset of the core API, because it is an encapsultation of CreateDialog API, that is itself a limited subset of the CreateWindowEx API.
- When you create an application that is built upon DDT, you limit yourself only to the features provided by DDT, that is less than 10% of the core API. And as soon as you want some fancy stuffs you realize that what you have learned using DDT leads you to a dead end, because it is a proprietary syntax that hides you what is realy going on behind the hood.
- PB is years back when compared to other languages that have built-in technologies like COM, OOP, DirectX, etc.
But fortunatly the PowerBASIC languages allows us to use directly the flat API, and thus learn from the MSDN C examples that are realy easy to translate to PB.
And once you learn it, then you learned it for ever what ever the language being used, because the syntax is always the same, and you become able to work arround the limitations of the high level language.
Now for the future of PB, i am confident that the next version will have some of the features found in modern programming languages, but I doubt that PowerBASIC will provide anything that would make the customization of a window something easier.
It is from the resort of third party addon providers to provide such tools, but the audience of PB is currently too small to make a living from that work, and this is the reason why i have ceased myself to promote WinLIFT on the PB's forum.
Patrice, you have stunned us all into silence. :o The designed of good controls obviously requires more than programming. Artistic skills to the fore! But I think the future GUI for most applications will come to rely on the embedded html driven browser. It does not make sense to duplicate all the capabilities that are so easily available and widely used in web pages. At present there are no built-in standards for vector graphics, 3d or video and while there are some good plugins available to fill these gaps, these should eventually become fully integrated as standard features in the repertoire of browser controls.
Writing a complete "VISUAL STUDIO" requires many qualifications and a dedicated team working aside the compiler's staff, and this means working around the EGO of the impetrant, that is probably the hardest thing to solve...
Speaking of the future:
Who has ever heard of WPF here?
Now the design of the graphic interface is not anymore the programmer's responsability, but the prerogative of the design team, just like in the game programming industry.
Quote
If I compare the look and style of these state of the art control, the possibilities of native
PB really look a bit old fashioned. What do you think ...?
You mean the native windows controls that provide the standard look and feel. Interface guidelines
seem to be falling by the wayside these days. Why on earth should I have to grab the mouse and move
it over some text just to figure out whether the you know what is a button? And then have to wonder,
is the thing clickable?
I have had a real example of such a meeting with marketing people some time ago, that was not a fictive story.
The link to these controls and framework suite was from them. What they said was "Your program is really good, but the way it looks we can't sell it."
Come back when it looks like its expected on the market.
I recommend all who are still in doubt, to take a look on the link here (this is the link they gave me):
http://www.infragistics.com/hot/vs2008/quick-comparison-winforms-vs2008.aspx#WindowsFormsQuickComparison
And the same things I heared before ever and ever.
If you have an Application on a WEB-Site it must look competitive or better then whats avaialable on the Market.
90% of People first look how it looks. Then they look if it works.
Thats the "woman problem" because every women knows "Men first look how i look, they do not ask how good i cook".
Patrice screenshots look nice, but these things are not actually integrated in any VD for easy usage - are they?
Thats what I would need.
I know that people who do not think marketing oriented may have other opinion and share their opinion with those Network Admins,
who still prefer the commandline even before ANY GUI.
But the real world goes the MAC-Way. Mac developed the mouse - everybody has a mouse tofay.
MAC started Glas, Aero, Silver. And thats what is expected.
And programming is NOT mostly for ourselves, at the end we may want to sell the programs.
And then you have to solve the woman problem. Get a Lift for your programms (WinLinft? :-)). Look good first.
Then at second look, the customers will take a look on functionality.
In our case, help others to look good. Using normal controls - no doubt - your programm will still be very functional.
But to continie with the picture - did you know fat women are often very good in cooking?
Anyway still most men will prefer those slim once - even if they finally find out that they are worse in the kitchen (thats why they are slim :-))?
Back to Patrice. Agin we have several different windows here. And thats typical for what we are doing here. The parts are there, but noone puts them together.
People expect NOT to have 10 windows on the desktop from one program. What they want is a "Framework". One big window, with all windows integrated.
Tabbed, and even they may want to move each window around and customize things.
Example? Take a look at this picture:
(http://www.okino.com/images/nrs_v4_450_snap_pitts.gif)
I know this program for several years since version 1.
There have not been so much changes in the software itself, but the same program comes now in a framework. No more separate windows.
Because thats what people expect. Some years before it was in several separate windows.
You can move the windows inside the framework around and configure all buttonbars user-specific.
The whole frame is really user canfigurable.
The number of programmer who may be able to do something like this in PB may not be that high.
Whats missing is a tool really - like VS - which helps beginners to get attractive looking programms.
Selling separate DLL's and separate VD shows only that these developer do only cook their own soup each,
but is not an alternative to the actual Software-developement Tools-Market.
State of the art is one tool that is competitive. Which not only would outperform all other "single tree - no wood" Tools, but also get new customers into the market!
What I think of, is a "wood - no more single trees" Tool. One that is integrated and competitive.
A product is competitive or it is not and then it is for a nishe-market only.
Competitiion is not only in a segment, but competitition is always in the overall market.
People must not use PB, they may use other thing too.
PS: If you don't believe me how important good looks is, ask you gf :-).
--Theo
Want to see a modern looking application, then see it there (http://www.zapsolution.com/windev/us/PAGE_Application.htm) ;)
(http://www.zapsolution.com/windev/us/res/fineco_meeting_A1052559_.gif)
Actually, this couldn't be done with PB, nor with any of the third party addon, i had to resort on a french tool to do it ;D
However i know how it could be done with PB with the help of either Paul and/or Dominic.
...
>Actually, this couldn't be done with PB
Huh?
Why not?
I can do about anything with PB but it's not worth my time to do so.
At the office i work for it's more internet nowadays, we purchase controls for .NET (devexpress)
I don't use this stuff at home, i would not like to bloath my 'hobby' stuff with this.
Not at this time...
The links found over here to the .NET controls are packages from 100 up to 300MB!
Not that it's required on redist but you can imagne the effort has to be made to these controls.
Do not underrate these controls and their work.
Dominic is also right but will 'lose the battle' against what users really need.
While the mouse might be needed and maybe even parts of these controls do not behave as should, usually the technical part and result brings the benefit (think: cost effective).
You can make the choice not to use 'a wrong control' or have the users benefit of the good part of these controls.
Or stick with standard controls where you won't get the time to realize the same (or better) behaviour as these custom controls offer.
We are the programmers, usually not really the end users.
I don't use the software i create, maybe in just a few occasions.
(I really don't care how it's been used :) )
--Why not?
Because of:
- split bar control.
- RTF with embedded images and paragraph fromating.
- spell checker.
- Full data grid input.
- Multi-user database (including client/server).
- Full skinned interface.
- Multi language support (I mean Arabian, English, Spanish, German, French, Chinese, Hebrew, etc.).
- Voice recognition.
- VISTA support.
- JAVA support.
- Linux support.
- XAML XML support.
- OCX support.
- Win32 support.
- DotNEt and Managed assembly support.
- OOP or procedural style.
Do you want more? :)
HTML, AJAX, SAP, Windows Mobile, Domotic, CD/DVD burner, Form recognition, TWAIN support, etc.
...
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.
QuoteThat'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 (http://www.windev.com)
About WPF, do not underestimate its impact (this remembers me when i first translated GDIPLUS to PB in 2002).
...
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 :-).
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.
QuoteThe 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.
...
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.
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. :)
Quote from: Chris Boss on February 25, 2008, 04:11:53 PM
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). :D
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
QuoteWe 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 ;D
...
You may push it but a tool is not a goal..
;)
Quotea tool is not a goal
Right you are, but always better to put a cherry on the cake :o
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!
>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.
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.
Chris,
Stability is for my applications most important. Second thing is development time. If I think i cannot end a project, i will simply not start. Thats why I used your EZ-GUI for my last project, it really saved me time on some corners. And its perfectly stable until now.
And then third important is, can I sell this program i was doing at the end?.
Generally I would never trade Design versus stability because I am not marketing oriented from my character.
Like >90% of all PB Users. :-).
If I would be marketing oriented (would think of sales first then of quality and stability), you may not find me here but using Standard Programms from M$. Maybe bad luck for me, because marketing orientation sells better.
About your unstable WINLIFT-Plugin.
If you have third party components in your tools and they have stability problems, then its your task to contact their developers and together get these problems out of the world. You can't leave this to your customers and say "its a third party tool maybe its their fault". Then its better, you don't talk about it so long it doesn't work.
If you have stability problems after a while, this could be resource problems, for example. In the easiest case this happens, if device context are not properly returned to the system.
As I am still developing under W2k, Resource problems show up easily on my PC and if these problems "come in the package" it would not be possible for me to develope my apps and at the same time search the problems of the tools I am using.
But if you get the things running, - lets say you get EZGUI-Windows look like those Patrice show up in his screenshots. This would be a big advantage for the end user.
I've also worked for big companies and yes they seem to not need nice GUI's.
As said, thats the case if you have already the contract from them or if they know you.
If they go on the market and there are several concurent products, wherever you go, often the bestlooking product with the same features is been taken at the end. Don't think the competitors do not have the same features.
About the "ownerdraw". I am not a designer, thats why I do not want to draw my controls myself ("Owner-draw" = the owner has to draw himself). We have 2008, if someone tells me that i have to draw my things myself to look competitive, I can only smile and say "thank you that you let me reinvent the wheel".
Paul is right, take a look here:
http://www.infragistics.com/dotnet/netadvantage/winforms.aspx
Then you'll see that even if I'd do that, i as a single person (with originally another thing in mind then to reinvent the wheel :-)) will not be able to do this things because I am not a designer. I think, even if I ownerdraw things, it may look rather worse then normal :-).
Its just a few years ago when we had the first generation of visul designer for PB. At a time when the rest of the world had VS for several years. I know people are working on the next generation. I think it would make sense to jump one step and make the third generation to not always be one step behind the rest of the world.
--Theo
Would you try this on your W2K computer?
http://www.jose.it-berater.org/smfforum/index.php?topic=1595.0 (http://www.jose.it-berater.org/smfforum/index.php?topic=1595.0)
...
It runs and produces two transparent windows on W2k.
Very elegant ... looks state-of-the art to me. Can say that this would suit me fine actually.
And as you said before - no matter how big the DLL's are I need for this.
Its just a question what project I am doing.
Something efficient? I can do it in PB.
Something for the public (must look elegant) ... don't know yet how to do it the easy way without reinventing dozens of wheels. :-)
Leaving aside complex controls like grids, much of the state-of-the-art design comes down to aesthetics and good artwork. We Humans like familiarity but not monotony. For neurological reasons, we find flat uniform surfaces (and sine wave tones) very tiring. So much of the contemporary look involves creating subtle shading and texturing of the surface - defocussing the inactive parts of the control and throwing functional parts into relief. Making buttons and slider knobs look like 3d objects is more than just gimmickry - it allows us to use more natural modes of perception, that do not cause fatigue.
There is of course a fashion element to all of this. - The Spring collection of List boxes,knobs and scroll bars by ... not to mention corporate styling.
Theo,
The reason I deactivated the plugin for WinLift is because I didn't want end users using it because of instability issues. WinLift appears to work fine in EZGUI apps, but the designer does a lot more than the typical application and over time the instability appears. It has something to do with creating/destroying forms over and over again, that causes the problem to appear.
WinLift's source code is far too complicated for me to spend the time trying to find a solution.
Also it is not my responsibility to find solutions for every third party tool that could be used with EZGUI.
If I did that, I would have no time for my own development.
When it is practical and reasonable though, I do provide feedback to third party developers to make their tools better suited to use with EZGUI.
I gave suggestions for tools like EGrid which improved their use with EZGUI. In particular the importance of using the standard WM_NOTIFY syntax for events (which EZGUI supports).
As far as using ownerdraw, read the docs about using the "Simplified Ownerdraw" command set. It is simply a few lines of code (no API knowledge needed) and you can customize the look of any control which supports ownerdraw.
For example to create a color list combobox like this:
(http://cwsof.com/ocombo.png)
Is as simple as this:
SUB TBAR2_FONTCOLORS_Events( MyID&, CMsg&, CVal&, Cancel&)
SELECT CASE CMsg&
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 items in the combobox simply are like this:
"<&HFFFFFF> White"
Where the actual RGB color is a hex number in <> brackets.
EZGUI takes care of the rest and does the drawing for you.
The simplified ownerdraw command set does a number of interesting things and can be used for menus, listboxes, comboboxes and listviews.
As far as 3D colored buttons, the Designer supports them directly. Just click the FG or Bg color buttons in the controls property dialog and when a color is selected it automatically converts the button to ownerdraw and generates all the necessary code for them. There are also two button plugins, which can be used to change the look and feel of the buttons.
In my case, the single factor that would make my decision to use a specific VS is:
Does it generates plain SDK source code or not?
Because i would avoid like the plague anything that is out of my control.
However i would be very glad to use a screen editor that would let me setup the control propreties like in VS2005/2008 and use my own graphic components to customize the aspect of the control (like in WinDev).
The WinDev screen editor, formaly HighScreen, is one of the best around, and if ever i have to collaborate on a VS PB project i would use it as the guidance to follow, including the way the code is tied to the control.
...
Reading the todays posts, I can agree to anyone who write here.
Or let me say it like that: We are all the same opinion on the points discussed.
In this case the discussion will soon be boring :-). hehe
Charles is right, there are elements of fashion in the design - not only of our clothes but also of our Apps and GUI's.
Chris is right about what he writes, but that doesn't remove the need for proffessional Designers (humans)
to generate really good looking stuff (see my link from the first post, Chris).
I know these possibilities are there and they save time for Apps to look a bit less grey.
But there is no switch for Glas and Aero and the Controls are not like those in the link.
About WinLift and Instability. Until I am completely shure, that its fully integrated and works 100% - even if the forms are 1000 times moved and removed, I won't use it. Because if I get resource problems because Memory is not properly freed the beauty is gone for me .-). As said, WinLift looks great, but it would be needed to be fully integrated somewhere to be more easy usable.
Could be a EZ-GUI Special Editon, but must be 100% stable - or no deal.
Also I agree that you as a single person cannot keep all combinations of how your tools "tested and bug free".
Thats why my word shall motivate you all to make more cooperations. Make something together.
Share your tools and ideas and get state-of-the art products out there.
And finally Partice ... I said already that I will look a closer look on this WinDev.
I will need something to make GUI's for my PB Programms. GUI's that are really competitive and not just mediocre.
Actually the amount of work using PB would be maybe to high.
QuoteAbout WinLift and Instability
Well i would like to say that WinLIFT is rock solid for me (all my commercial applications are using it).
Indeed there are two WinLIFT flavors, one works like the zSkin.inc i did share with you, and one works as a subclassing engine to skin existing controls on the fly, and both are ownderdrawn based.
The problem with the subclassing engine is that it must decipher the class being used to skin the control properly, ie: if the class name is "Button" I know what to do, but in case of superclass or private control using unknown name i don't know what to do.
In the case of EZGUI i had to do this:
IF LEFT$(UCASE$(zTxt), 6) = "EZGUI_" THEN
EffectType& = %SKEFF_SCREENSHOT
END IF
of course this is not viable in the long run to support each of the VS using their own class name.
Hence the reason why i give it up.
But of course i know how to do it in case of a dedicated VS project, he he!
Here is how the
WSA works to decode the class being used (WSA = WinLIFT Simplified API)
FUNCTION EnumChildProc(BYVAL hWnd&, BYVAL lParam AS LONG) AS LONG
LOCAL bt AS SKALL
LOCAL rc AS RECT
LOCAL cs AS COLORSCHEME
LOCAL pt AS POINTAPI
LOCAL zChildClass AS ASCIIZ * 32
IF GetClassName(hWnd&, zChildClass, SIZEOF(zChildClass)) THEN
hParent& = GetParent(hWnd&)
ItemParent& = skItem(hParent&)
zChildClass = UCASE$(zChildClass)
MDICLIENT$ = "MDICLIENT"
IF INSTR(zChildClass, MDICLIENT$) THEN zChildClass = MDICLIENT$
' May I skin the control?
IF NOT skSkinActive(hWnd&) THEN FUNCTION = %TRUE: EXIT FUNCTION
SELECT CASE CONST$ zChildClass
CASE "MDICLIENT"
IF GetParent(hParent&) = 0 THEN Win(ItemParent&).hMdiClient = hWnd&
CALL DeleteObject(SetClassLong (hWnd&, %GCL_HBRBACKGROUND, CreateSolidBrush(skGetSysColor(%SKCOLOR_INACTIVECAPTION))))
' Should we handle this big mess
CALL skMonitorCtrl(hWnd&, %CTRL_MDICLIENT)
CASE "TOOLBARWINDOW32"
IF GetParent(hParent&) = 0 THEN
CALL skMonitorCtrl(hWnd&, %CTRL_TOOLBAR)
cs.dwSize = SIZEOF(COLORSCHEME)
cs.clrBtnHighlight = skGetSysColor(%SKCOLOR_3DRIGHTBOTTOM)
cs.clrBtnShadow = skGetSysColor(%SKCOLOR_3DLEFTTOP)
CALL SendMessage(hWnd&, %TB_SETCOLORSCHEME, 0, BYVAL VARPTR(cs))
ELSE
CALL skMonitorCtrl(hWnd&, %CTRL_TOOLBAR)
cs.dwSize = SIZEOF(COLORSCHEME)
cs.clrBtnHighlight = skGetSysColor(%SKCOLOR_3DRIGHTBOTTOM)
cs.clrBtnShadow = skGetSysColor(%SKCOLOR_3DLEFTTOP)
CALL SendMessage(hWnd&, %TB_SETCOLORSCHEME, 0, BYVAL VARPTR(cs))
CALL DeleteObject(SetClassLong (hWnd&, %GCL_HBRBACKGROUND, BYVAL %NULL))
CALL SetWindowLong(hWnd&, %GWL_EXSTYLE, GetWindowLong(hWnd&, %GWL_EXSTYLE) OR %WS_EX_TRANSPARENT)
Child(skChild(hWnd&)).paintflag = %TRUE
END IF
CASE "MSCTLS_STATUSBAR32"
CALL skMonitorCtrl(hWnd&, %CTRL_STATUS)
CALL SetWindowLong(hWnd&, %GWL_EXSTYLE, GetWindowLong(hWnd&, %GWL_EXSTYLE) OR %WS_EX_TRANSPARENT)
IF ItemParent& THEN Win(ItemParent&).hStatus = hWnd&
CASE "BUTTON"
WasStyle& = GetWindowLong(hWnd&, %GWL_STYLE)
IF (WasStyle& AND %BS_GROUPBOX) = %BS_GROUPBOX THEN
CALL GetClientRect(hWnd&, rc)
CALL skMonitorCtrl(hWnd&, %CTRL_GROUPBOX)
CALL SetRect(Child(skChild(hWnd&)).rc, 0, 0, rc.nRight, rc.nBottom)
CALL SetWindowLong(hWnd&, %GWL_EXSTYLE, GetWindowLong(hWnd&, %GWL_EXSTYLE) OR %WS_EX_TRANSPARENT)
ELSEIF (WasStyle& AND %BS_CHECKBOX) = %BS_CHECKBOX THEN
UseStyle& = %CTRL_CHECKBOX
IF (WasStyle& AND %BS_OWNERDRAW) = %BS_OWNERDRAW THEN
UseStyle& = UseStyle& + %CTRL_OWNERDRAWN
END IF
CALL skMonitorCtrl(hWnd&, UseStyle&)
ELSEIF (WasStyle& AND %BS_AUTOCHECKBOX) = %BS_AUTOCHECKBOX THEN
UseStyle& = %CTRL_CHECKBOX
IF (WasStyle& AND %BS_OWNERDRAW) = %BS_OWNERDRAW THEN
UseStyle& = UseStyle& + %CTRL_OWNERDRAWN
END IF
CALL skMonitorCtrl(hWnd&, UseStyle&)
ELSEIF (WasStyle& AND %BS_RADIOBUTTON) = %BS_RADIOBUTTON THEN
UseStyle& = %CTRL_RADIOBUTTON
IF (WasStyle& AND %BS_OWNERDRAW) = %BS_OWNERDRAW THEN
UseStyle& = UseStyle& + %CTRL_OWNERDRAWN
END IF
CALL skMonitorCtrl(hWnd&, UseStyle&)
ELSEIF (WasStyle& AND %BS_AUTORADIOBUTTON) = %BS_AUTORADIOBUTTON THEN
UseStyle& = %CTRL_RADIOBUTTON
IF (WasStyle& AND %BS_OWNERDRAW) = %BS_OWNERDRAW THEN
UseStyle& = UseStyle& + %CTRL_OWNERDRAWN
END IF
CALL skMonitorCtrl(hWnd&, UseStyle&)
ELSE
IF (WasStyle& AND %BS_OWNERDRAW) = %BS_OWNERDRAW THEN
CALL skMonitorCtrl(hWnd&, %CTRL_PUSBUTTON + %CTRL_OWNERDRAWN)
ELSEIF (WasStyle& AND %BS_ICON) = %BS_ICON THEN
CALL skMonitorCtrl(hWnd&, %CTRL_PUSBUTTON + %CTRL_OWNERDRAWN)
ELSEIF (WasStyle& AND %BS_BITMAP) = %BS_BITMAP THEN
CALL skMonitorCtrl(hWnd&, %CTRL_PUSBUTTON + %CTRL_OWNERDRAWN)
ELSE
CALL SetWindowLong(hWnd&, %GWL_EXSTYLE, GetWindowLong(hWnd&, %GWL_EXSTYLE) XOR %WS_EX_DLGMODALFRAME)
Label$ = skGetCTLText(hWnd&)
ID& = GetDlgCtrlID(hWnd&)
EnableMode& = IsWindowEnabled(hWnd&)
IF ID& >= %ID_DOCKOUT AND ID& <= %ID_CLOSE THEN ID& = 0
IF ID& THEN
CALL GetWindowRect(hWnd&, rc)
xBut& = rc.nLeft
yBut& = rc.nTop
ButWidth& = rc.nRight - rc.nLeft
ButHeight& = rc.nBottom - rc.nTop
CALL SetWindowLong(hWnd&, %GWL_STYLE, WasStyle& OR %BS_OWNERDRAW)
bt.Button = 1
UseFont& = SendMessage(hWnd&, %WM_GETFONT, 0, 0): IF UseFont& = %NULL THEN UseFont& = skDefaultFont
CALL skDrawBut3D(hWnd&, Label$, UseFont&, ButWidth&, ButHeight&, bt)
CALL skMonitorCtrl(hWnd&, %CTRL_PUSBUTTON)
END IF
END IF
END IF
CASE "SYSTABCONTROL32"
CALL skMonitorCtrl(hWnd&, %CTRL_TAB)
CALL DeleteObject(SetClassLong (hWnd&, %GCL_HBRBACKGROUND, GetSysColor(%COLOR_3DFACE)))
CALL GetWindowRect(hWnd&, rc)
xOffset& = rc.nLeft: yOffset& = rc.nTop
XX& = rc.nRight - rc.nLeft: YY& = rc.nBottom - rc.nTop
CALL SendMessage(hWnd&, %TCM_ADJUSTRECT, %FALSE, BYVAL VARPTR(rc))
hRgnClip& = CreateRectRgn(0, 0, XX&, YY&)
xOffset& = rc.nLeft - xOffset&: yOffset& = rc.nTop - yOffset&
XX& = rc.nRight - rc.nLeft: YY& = rc.nBottom - rc.nTop
hRgn& = CreateRectRgn(xOffset&, yOffset&, xOffset& + XX&, yOffset& + YY&)
CALL CombineRgn(hRgnClip&, hRgnClip&, hRgn&, %RGN_DIFF)
CALL skDeleteObject(hRgn&)
CALL SetWindowRgn(hWnd&, hRgnClip&, %TRUE)
CASE "#32770"
CALL skMonitorCtrl(hWnd&, %CTRL_DIALOG)
CASE "STATIC"
CALL skMonitorCtrl(hWnd&, %CTRL_STATIC)
IF SendMessage(hWnd&, %WM_GETFONT, 0, 0) = %NULL THEN ' Bernard
CALL PostMessage(hWnd&, %WM_SETFONT, skDefaultFont, 0)
END IF
CASE "SYSTREEVIEW32"
CALL skMonitorCtrl(hWnd&, %CTRL_SYSTREEVIEW)
UseColor& = skGetSysColor(%SKCOLOR_CAPTIONTEXT)
' Check if UseColor& doesn't conflicts with the &hFFFFFF transparent background
IF UseColor& = &hFFFFFF THEN UseColor& = RGB(250,250,250) ' RGB(255,255,254)
CALL SendMessage(hWnd&, %TVM_SETBKCOLOR, 0, &hFFFFFF)
CALL SendMessage(hWnd&, %TVM_SETTEXTCOLOR, 0, UseColor&)
CALL SendMessage(hWnd&, %TVM_SETLINECOLOR, 0, UseColor&)
CASE "LISTBOX"
WasStyle& = GetWindowLong(hWnd&, %GWL_STYLE)
IF (WasStyle& AND %LBS_HASSTRINGS) THEN
CALL skMonitorCtrl(hWnd&, %CTRL_LISTBOX)
END IF
CASE "MSCTLS_TRACKBAR32"
CALL skMonitorCtrl(hWnd&, %CTRL_TRACKBAR)
CASE "SYSLISTVIEW32"
CALL skMonitorCtrl(hWnd&, %CTRL_LISTVIEW)
CALL SendMessage(hWnd&, %LVM_SETBKCOLOR, 0, skGetSysColor(%SKCOLOR_INACTIVECAPTION))
CALL SendMessage(hWnd&, %LVM_SETTEXTCOLOR, 0, skGetSysColor(%SKCOLOR_CAPTIONTEXT))
CALL SendMessage(hWnd&, %LVM_SETTEXTBKCOLOR, 0, skGetSysColor(%SKCOLOR_INACTIVECAPTION))
CASE "SYSHEADER32"
LOCAL pHD AS HD_ITEM
HeaderCount& = SendMessage(hWnd&, %HDM_GETITEMCOUNT, 0, 0)
IF HeaderCount& THEN ' Check if we can skin it or not
DoIt& = -1
FOR K& = 0 TO HeaderCount& - 1
pHD.Mask = %HDI_FORMAT
CALL SendMessage(hWnd&, %HDM_GETITEM, K&, VARPTR(pHD))
IF (pHD.fmt AND %HDF_OWNERDRAW) = %HDF_OWNERDRAW THEN DoIt& = 0: EXIT FOR
IF (pHD.fmt AND %HDF_BITMAP) = %HDF_BITMAP THEN DoIt& = 0: EXIT FOR
IF (pHD.fmt AND %HDF_BITMAP_ON_RIGHT) = %HDF_BITMAP_ON_RIGHT THEN DoIt& = 0: EXIT FOR
IF (pHD.fmt AND %HDF_IMAGE) = %HDF_IMAGE THEN DoIt& = 0: EXIT FOR
NEXT
IF DoIt& THEN CALL skMonitorCtrl(hWnd&, %CTRL_SYSHEADER)
END IF
CASE "RICHEDIT"
CALL skMonitorCtrl(hWnd&, %CTRL_RICHEDIT)
CASE ELSE
CALL skMonitorCtrl(hWnd&, %CTRL_UNDEFINED)
END SELECT
END IF
FUNCTION = %TRUE ' continue enumeration of children...
END FUNCTION
The problem of Chris, is that WSA was not designed to change its graphic components on the fly (it does this only once, during process initialization).
This must be handled like in the WinLIFT standard version using native's WinLIFT controls.
Or like VS2005/2008 or WinDev does, each of the control could have an associated bitmap, when you select the customize property (ownerdrawn).
...
Can't you explain it directly to Chris, so he can integrate it in EZGUI - how it is meant to be - ?
This would be a very good combination to the advantage of you both.
But there should be a really good integration which is absolutely stable.
A halfstable "just run it once" thing or something where I need to walk extra rounds to get the advantages is not what I need.
Such half done bussiness is worse then nothing.
And me as potential customer cannot be asked to repair things not made complete at design time, unless its been released as freeware :-).
--Theo
As i said already, i would be glad to cooperate with a tool looking like the visual designer of VS or Windev, as long as it is able to produce plain SDK code, but anything else I am not interrested in, and this would also apply to DDT and the CreateDialog API.
...
Theo,
It is not a matter of either product being unstable, but that they were not intended to work together.
Like I said, WinLift works fine at first, but when loading and unloading forms in the designer, winlift develops an instability and can GPF.
Like Patrice said, WinLift was not designed for such use.
The effort to make two totally different products like these compatible would require a lot of effort.
Its different with say custom controls, because they are designed to be used by other software. If they are designed correctly, then compatibility is rarely a problem.
WinLift on the other hand "takes control" of things and by subclassing overrides default actions of the calling app.
This likely requires specific "rules" in how this is done.
I found that the problem with WinLift appears to be that it didn't like other windows (dialogs) being created which are not skinned, while using the skin engine for the rest (the projects forms). I guess if I let winlift skin the entire designer, that might make a difference so all the windows are skinned. I didn't try that and neither did I want to, because most customers don't use winlift and the designer was made to work with the standard look and feel of windows.
I guess it would be possible to make a purely winlift edition of the designer. I don't know if that would work or not.
Ok, Chris, I think this explanation shows me where we think the problem is.
WinLift expects the whole Designer app to be skinned.
I think we can drop that now, while EZ_GUI is more near to SDK-Code then DDT,
but its not plain SDK therefore Patrice will not be interested in this case a lot.
As a conclusion, on this topic, I'd say that we just wait and see if any of the developers sees the need for a competitive design in the future and makes it easy to geth hands on this design.
In my actual project its not intersting, therefore i have no real hurry on that.
I;m not a graphics designer, but I can tell you that if you want to see PowerBasic or any other compiler become graphics centric, you have a real problem, because what's visual and what does on underneath are two distinctly different things. First of all, the traditional way to program has been to analyze the task and code it as an algorythm, which takes the form of a programming language, and that consists of logic, determinants, values, constants, and branches, all expressed as written words and numerical symbols.
But graphics are... well, graphical. It was a real advance to find a way to express graphical elements as tags, because now they are insertible into written structures, and these can be made part of a programming language, and we do this with web pages. But have you looked at the horrible mess that results? Try to read your way though the source code for a web page and see if you can make that relate to the visual appearance and behavior of the page as seen. It has taken us decades to finally narrow the interpretations of html documents so that all browsers pretty much view them the same, but with some minor variations still. Yet there are always some sites that one browser or another may not display or react to properly. And now we see XML and AJAX (among other technologies) trying to take center stage.
What we are saying, is that to do these things, you have to learn to do these things. Graphical Designers learn their trade the hard way, and the problem is, for what you gain, few people want to have to make the same journey. So instead we ask the Graphical Designers, can't you guys find a way to make it simple for the rest of us? And the answer is, that they can write software that we can incorporate into our own products, but you still have to learn to use it, and in fairness you need to pay additional to get it.
To learn graphics, you have to master new concepts. A part of this is learning things, like the names of controls, parameters, and constants. These have to become part of our language and thought processes. To avoid doing this, we would have to follow a different path entirely, meaning we would have to get away from words and tags and instead resort to... graphics.
What if we could visually design things? This is what lead to Visual Basic, PBForms, DDT, and other tools. They were made simple so that we could master them. But now average programmers are forced to compete with Graphics Designers for customers, asnd the programmer is coming off second best, because the part he labors the hardest over is not visible. Instead, he is being asked to put more effort into the visual part, and he finds that unfair, and a real threat to his overall productivity.
So how do we resolve this? I really don't know. I do know that as long as everyone takes a different road towards a solution, we end up with a fragmented market. So the idea that Graphical Designers should band together to benefit the programmer base has merit, in that a common appoach would be better at the onset. But thje other thing, is that to ask programmers to take the long road of learning concepts and language skills for doing graphics is not going to be the easy or quick way.
I think the right approch has to center on using graphics to illustrate choice, then selecting the effects desired. Suppose you consider a single image that you were working on in a graphics manipulation program, possibly a photo editor. You have the many choices of changing the gray scale, hues, saturation, contrast, brightness, and so on. A good editor might preview what some of the effects could do at different settings wieh a series of thumbnail images. If you see an effect you like, you could either select that, or adjust a scale to get you in the vicinity of looking like that. After that, you could save your work, and immediately see more choices of how the image could be further refined.
Now think of an object that is a composite of visual aids and controls. You want the ability to modify both, at the same time, and continue to see how they interact with each other. You need the ability to interact as though a user, as the graphics developer, and where necessary, at the lowest coding level, and to be able switch between these views with ease.
If someone were to devise the engine for managing all this, then perhaps other developers can see their way to go after effects that can be modulated to work with this engine. Now that is an approach that might help bring developers together in a common purpose.
QuoteWe 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.
I think this sentence is woth a quote and a good end for the post.
It says in one sentence what I would like to have with PB also.
I think that is only partially true..
I think this is a programmers perspective.
Is that a programmer's perspective ?
(http://www.zapsolution.com/pictures/Caisse.jpg)
...
If you *have* eye-candy.. fine..
If not it does not mean perse that the app will not sell.
Btw, there are different targets, for businessapplications things are really different than for example a game.
Therefore you can not say: "..the biggest single factor.."
Btw, from looking at your snapshot.. i even feel stronger that a 'normal' looking app can be as successful as you did with the above.
As long the interface is equally easy to handle.
The eye-candy seems (to me) as unnecessary in this case, good you do but not required i guess.
In the long run a more eye-candy app could become more popular, that's for most buyers not the first requirement.
QuoteAs long the interface is equally easy to handle.
It is just a matter of
using the right tools to do it,
that is a
themed application that must conform to a specific user's Chart.
I shall have soon another one to do for an important pharmaceutical group, with respect of their medical chart to "facelift" one of their current Windows XP application that they find "old-fashioned".
(http://www.zapsolution.com/pictures/Oleigest.jpg)
The name of the tool being used to do it, is shown on the Windows status bar (+ GDImage).
...
I know where this is going, a remark, an opinion, confusion.
+ It has nothing to do with critic on your app or so.
I think you are saying that it is (for you) equally much of work to accomplisch what you do compared with an ordinary app.
And that's not the point here.
Let's talk about business apps only, my opinion is that an app can be sold (equally) fine as it where an ordinary but friendly gui.
+ Does one really purchase MS Word for it's ribbon control or it's looks anyway?
The point is:
If you give the choice to the end user between two accounting programs, one with a nice looking interface and one with a "classic" look, and even if the nice looking interface if sold 1.5 the price of the "classic" one, the user will choose the nice one as long as the psychologic price is good.
But of course you can always drive from point A to point B with a Trabant car :)
And you can also make love with an old sixty or with a younger, the choice is yours and the result would be probably the same, but i guess you would probably pay more for the younger ;D
[OT]
Quote
But of course you can always drive from point A to point B with a Trabant car :)
Why not ? (click ) (http://www.praguepost.com/articles/2007/09/05/filmmakers-tour-asia-by-trabant.php)
[/OT]
Patrice,
your application looks great, as usual :)
Regarding the importance of program look ... I think it depends a lot on who is the customer.
I think there is some thin line between good enough and "ugly" program.
So from some point I think well looking application with classic Win32 controls and Windows look and feel can compete even with eye candy.
The worst psychologic impact have details like not consistent size of buttons or too wild GUI, which indicate beginners work ( yes my proggies still suffer from this ).
Sill, I have seen case when quite a big institution bought program which:
- Was crime against aesthetics
- It had Form1 in window caption instead of something logical ( along with default Delphi icon indicating the dev. tool :) )
- Had crash around every corner
... even with such a flaw somebody payed for it :) I hope it is an exception.
Bye,
Petr
Patrice,
it is very clear that your applications are not only beautifull looking but full of little details, every piece of UI seems at the right position, every control is studied for a target not only for candy. So, to me, it is clear that you are a very high pro that cure all aspects and details.
That said, in my experience, many time candy are there just to cover very poor application design, very little cure in details and in application functionalities. In few words: to get money from users that fall in love for external aspects but later, when they will search for functionalities, will remain disappointed.
I think that I am here completely with Patrice.
At the end I think that anyone who has ever tried to sell an application to the "unknown end user" will agree.
Only those of us, who try to sell to sell to a group of "known users" or to deliver an ordered application to a known customer will not have that "his daughter looks better then mine" problem.
Let me pose this matter in my own unmistakable way.
Two apps may do the same thing, but the app with the more polished and impressive image will draw more attention.
Cutomers, business or otherwise, would rather by a product that looks better, because it is more appealing, and because a polished image would seem to indicate more attention to detail.
The more attractive product offers visual assurances that the product is overall of better quality. We tend to judge everything this way. Now a mechanic may know that one car is actually better than another because of the engineering that went into the motor, transmission, stearing, and everything else, but most customers will be lured by looks and how it feels to sit in the driver's seat and hear the engine purr.
If a customer prefers one product over another based on visual impact, then the difference means either buying the more attractive or impressive product if the prices are about the same, or possibly paying a bit more for the product that they put greater value in.
You could probably take an older model car that still runs well and pay someone a few thousand dollars to restore it to a point that it almost feels like a new one. Or you could spend ten times as much and actually get a new car. Most people get a new car, not because they want to spend all that money, but because it is a new car. It looks new, and other people will know that it is new, so it is about personal satisfaction and status.
Some people will take a rusty old car and restore it, then sell it for three to ten times the cost of a new car. It looks beautiful because of the detailed rework, but underneath the glossy finished is a rusted shell held together with bondo and lead filler. We can't see below the surface, so even though we know what is underneath, the image presented convinces us that this junker that just recently got a major face lift is somehow worth it.
Software isn't any different, because people aren't any different. Dealing with programmers and other technical sorts, we can sometimes bond and sell something based on the inner beauty of how it works, or what it does, of its elegance in architecture. But that's not the general buyer, and management is got its own objectives to meet, like convince upper management that they got their money's worth in buying a new program or upgrading an existing one. They might even want to shock and awe their own customers by showing off the tools that they use inhouse.
You guys keep on 'comparing' !
I am not talking about a situation where one can pick the normal or eye-candy version.
I say that the normal version can be sold equally fine.
I said that an enhanced gui like P. shows at the end may be more popular.
But no-one can tell.
Often nice looking software is just that... and hides it's problems this way.
If the gui is nicer looking but works slow and poorly, the customer can not know that a normal version can work much better.
They can not compare.
You are programmers and think what people want.
I prefer a stable and easy to use program over enhanced and having side-effects.
"Geeh it sucks, but it looked great"
--
Note that customers also work with very poor software, they often do not blame the software but themselves.
They blame themselves it's not a handy thing to work with and want to adapt.
If i hear this i tell them "you should have thrown that away 10 years ago"
This is the moment the light-bulb goes on..
QuoteThat said, in my experience, many time candy are there just to cover very poor application design
Well, that means that we do not share the same experience. 8)
Quote"Geeh it sucks, but it looked great"
Amazing, why the heck a nice looking interface would be a synonym of slow and poorly programmed application. ???
A nice user interface is like good packaging, it helps to stand out of the crowd, but it could be also considered as the emerging part of the iceberg. Because if you are able to manage all the aspects of a window, you probably have a good knowledge of the underlaying OS and thus the immersive part would probably be as good as the emerged one.
On the contrary of DOS, Windows is a native graphic environment.
At first, most of the success of VISTA in the skinning communities was based on the new AERO interface, while XP is still fine to use, its interface now looks older because there is just a new standard. Mode effect, perhaps, but ask a lady how she wants to be dressed up then you will soon get the picture.
The
Oleigest application from where i did post the screen shots, is still written in DOS PB7, and to convince the users
to pay good money to upgrade to the new Windows version, there was more to do than just porting it to Windows.
Here is a screen shot of the "Product" window,
that has not yet been themed, but it would help you to figure the type of tool we are using to manage this huge Windows portage.
(http://www.zapsolution.com/pictures/environment.gif)
Note: None of the existing PB third party addon would have been able to do that.
And my responsability as project manager was to
select the best tool to do it, and that would let us do it in the shortest delay.
...
>2100 Viewers, by now this topic has most viewers from all the topics.
This alone shows us that "look and feel" is something that is interesting for people.
I hope Bob has read it and thought about it, too.
Anyway, its time that a third party makes something about it, thats easy to use and as stable as powerbasic.
Regarding skins, a few years ago i could paint any part and even size it to desired framewidths.
The only issue was the first topmenu offset i couldn't change.
I dropped it but later on i thought that even that could have been solved using ownerdraw topmenu.
To bad i a have no fun in pursuing, i don't care for skins, just wanted to see how far i could come with that.
No secundairy windows for the non-client areas.
Chris,
Better move things related to WinLIFT there:
http://www.jose.it-berater.org/smfforum/index.php?topic=3222.0 (http://www.jose.it-berater.org/smfforum/index.php?topic=3222.0)