Re: [DUG]: RE: Fixing the VCL (LONG)
Mark Derricutt wrote: Max Nilson wrote: There are already a couple of OpenSource type efforts underway to do a VCL type library based on one of the X toolkits for the Free Pascal Compiler (FPK). Yup, there's Medigo (i think) which is doing it's MCL wrapper around GTK which should rock, they're also planning a full development RAD environment too :) www.megido.org, and they're looking for volunteers. --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
RE: [DUG]: RE: Fixing the VCL (LONG)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Carl Reynolds Sent: Friday, 12 March 1999 12:37 To: Multiple recipients of list delphi Subject: RE: [DUG]: RE: Fixing the VCL (LONG) Max Nilson [[EMAIL PROTECTED]] wrote: There are two main problems with marketing any Delphi component from our experience. One is that the time to properly document a component is fairly long, almost as long as it takes to write them. The other is in having enough time to spend actually marketing the component, that is, placing it on all the Delphi sites, sending news messages to the most useful places, trying to get people to link to your sire etc. Then you also need to consider the technical support costs as an on going thing for the company... All true, but it needs to be balanced against the potential gains that are available. Perhaps too few of us are prepared to really attempt to market our own components. You imply that you've tried it, though? Because Profax's focus is on products rather than components it become very hard to justify this kind of money for the pitiful returns that can be achieved. We are open to offers to handle the documentation and marketing for us from anyone who can provide good references in this area. Ok, well I can't help you there - we haven't published any components ourselves (who has, on this list? How successful were you?). But, correct me if I'm wrong, I think there is a very large and potentially very lucrative market out there, not just "pitiful returns"... We published one component that Max wrote as a test of the market, it was a much improved field editor for dataset's. Although we had a lot of interest and hundreds of people from all over the world downloaded it, only a handful purchased it. It cost far more to release it than we made from sales. I thought perhaps we needed a timelock, but the version we published only worked for D3 so we effectively had a timelock. It would have been lovely to have at least covered our costs but it did not happen so we were unable to release any more of our components. --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: RE: Fixing the VCL (LONG)
Modify or Re design the VCL??? You guys a gotta be in ga ga land. Man, like this is bullshit. Max Fox was onto it, and said it all for me.I mean lets get a little practical about all this. Are all your egos so inflated that you actually think you can out do the guys in Borland ??? So why are you still in this country working at all??? let me ask you all one question... Have you seriously read and understood Borlands code? No, I don't want to be flamed, thats why I left this list before for a year C-Ya, Tony -Original Message- --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: RE: Fixing the VCL (LONG)
Modify or Re design the VCL??? You guys a gotta be in ga ga land. Man, like this is bullshit. Max Fox was onto it, and said it all for me.I mean lets get a little practical about all this. Are all your egos so inflated that you actually think you can out do the guys in Borland ??? So why are you still in this country working at all??? let me ask you all one question... Have you seriously read and understood Borlands code? The intent was not to rewrite all of borlands code... much of it is fine but there several base controls which could benefit from a ground up rebuild and in the nature of OOP can provide an incremental approach to providing a richer set of controls - preferably designed to be extended at the outset instead of wrapped up control hacked up to provide entensibility. No I don't understand ALL of borlands code, I have read some and the understanding has not been that difficult - better documentation of intent for much of the methodology would assist of course... By beginning an open source project, skills in documentation and learning of detailed windows programming can be gained by other members of this list more rapidly than the piecemeal, hit and miss approach of asking when stuck... The results of this work may or may not present direct benefits to our product development but they will serve to teach and to illustrate shortcomings and solutions in existing delphi development. No, I don't want to be flamed, thats why I left this list before for a year C-Ya, Then your wording could do with some work... Much of the discussion of the VCL shortcomings are inflamatory - the development of a solution will be more beneficial for learners and provide a testing ground for experienced designers. In short let's not be so negative... The number of list members and their range of skills is a formidable resource... -- Aaron@home --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: RE: Fixing the VCL (LONG)
I hate to bring the flogging of dead horses back, as thats just criminally insane. But when this VCL thread started a few days ago, an immediate thought came to mind. Max/Ian have spoken at great lengths decribing how to replaced TEdit and the Grids, I wonder, how much do these new controls rely on the underlying Win32 API Some of you may guess what I'm thinking, the common argument again a Delphi for Linux is the VCL, because it is heavily tied to the Win32 API, if we start work on a partial VCL replacement that provides us with a decent set of controls that perform how we want, that isn't directly tied to the Win32 API, could such a VCL for linux be made? Would it be possible to write these things in such a way that we abstract any Win32 specifics out of the system, so that a GTK, QT, or even Motif back end be used to provide cross platform cababilities? Any thoughts Am I dreaming without a pillow as usual or what?? Mark Aaron Scott-Boddendijk wrote: Modify or Re design the VCL??? You guys a gotta be in ga ga land. Man, like this is bullshit. Max Fox was onto it, and said it all for me.I mean lets get a little practical about all this. Are all your egos so inflated --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
RE: [DUG]: RE: Fixing the VCL (LONG)
-BEGIN PGP SIGNED MESSAGE- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mark Derricutt Sent: Friday, 12 March 1999 23:40 To: Multiple recipients of list delphi Subject: Re: [DUG]: RE: Fixing the VCL (LONG) snip Some of you may guess what I'm thinking, the common argument again a Delphi for Linux is the VCL, because it is heavily tied to the Win32 API, if we start work on a partial VCL replacement that provides us with a decent set of controls that perform how we want, that isn't directly tied to the Win32 API, could such a VCL for linux be made? Would it be possible to write these things in such a way that we abstract any Win32 specifics out of the system, so that a GTK, QT, or even Motif back end be used to provide cross platform cababilities? Any thoughts Am I dreaming without a pillow as usual or what?? The origins of Object Pascal were with Apple. They managed to implement it without the Win32 API. Serioucsly I think that the current projects for porting a Delphi like system to Linux are worth looking at. Anything that is designed to run on Windows is heavily dependent on Windows architecture. IRD is currently copping a lot of heat in the media because they insist that employers file their PAYE returns via a web page containing ActiveX controls, which of course are MS Windows proprietary :) Patrick Dunford, Christchurch, NZ PRO VSM - Human Rights for Students! http://patrick.dunford.com/ -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.0.2i iQEVAwUBNuhLfIQbtaGa2X4LAQEomwf9GsfPWZ/CUyiLwCGhn/EB4kApTRyqcva5 99wZNwWQZXzAHgocVm49gOZNCWo+P/WKIPZhWsu/ON2ViULNMHqLaB8sbfvxC5tz vQNNjbdBikiOwuagJbihyp+0/pvpfmcy+6SFefhAXAUtbRNUh4br+RZ7uBT1vr8W DluKTwP4ELLWMaj6uxDyAA+aJayXrv0P5T8Cb4h3ydffa+gJgpy8mDaTOkBe3T6o vjwxSImGrpwW3oSuiEJMVjXBpne2dPE6OEuhHcXydF7sDwqx6cQiVPvKenf37OxH ptEFxyw5F0J7Y6X8rIBaN7ZZagsvQeXv76ReDEKJPc//XaqsKhQWfQ== =P4p9 -END PGP SIGNATURE- --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: RE: Fixing the VCL (LONG)
The origins of Object Pascal were with Apple. They managed to implement it without the Win32 API. Object Pascal has nothing to do with the VCL - aside from that fact that its written in OP. OP has NO ties Win32. The VCL is build on Win32, it exists around its messaging model etc. If you have a hunt around in system.pas etc, you can see that there is a LOT of low level crap there (99% of which is ASM) to translate from procedural/message based to OO/message based. And its far from pretty (tho it does work very well) Oh, and the OP on the mac is, well, rather different, as far as I can remember, to delphi. Some of the basics are the same, but over all - different beast (Delphi is way ahead). Serioucsly I think that the current projects for porting a Delphi like system to Linux are worth looking at. Definatly. I can't agree more. All thats needed is an OP compiler (ala FreePascal?), some way to import the libX shared libs (taking Linux as an example) and about 3 man-years or more of time. Unpaid. No thanks. I have quite enough on my plate at present. Anything that is designed to run on Windows is heavily dependent on Windows architecture. IRD is currently copping a lot of heat in the media because they insist that employers file their PAYE returns via a web page containing ActiveX controls, which of course are MS Windows proprietary :) :) Kinda. ActiveX will run under MacOS and Unix. But not the same binary (not even close). If they have done this (and AFAIK, from IDG, they have), they have screwed quite a few pooches in one hit. Well done. Only IBM and and Police thing could do it better Not a good look. :) Nic. --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
RE: [DUG]: RE: Fixing the VCL (LONG)
Ian wrote: I thought perhaps we needed a timelock, but the version we published only worked for D3 so we effectively had a timelock. You almost certainly needed some kind of lock or nag. "...only worked for D3..." basically means: a) Anyone using D3 gets it for free b) Anyone using D4 thinks it is no good In our case (TCompress et al), we've never settled for less than an occasional nag, and I'm sure that was a wise decision in the hard currency sense. In other words, your market test may have been testing the wrong thing -- if you weren't converting 5-10% of downloaders into sales, the formula was wrong somewhere... cheers, peter Peter Hyde, SPIS Ltd, Christchurch, New Zealand * TurboNote: http://TurboPress.com/tbnote.htm -- small, FREE and very handy * Print-to-Web automation http://TurboPress.com * Web design, automation and hosting specialists Find all the above and MORE at http://www.spis.co.nz --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: RE: Fixing the VCL (LONG)
Max Nilson wrote: 100% pure GDI and Windows event handling is used in the production of these new controls 8-) Eeek :) I fear to tread on even LOOKING at that code Max :) There are already a couple of OpenSource type efforts underway to do a VCL type library based on one of the X toolkits for the Free Pascal Compiler (FPK). Yup, there's Medigo (i think) which is doing it's MCL wrapper around GTK which should rock, they're also planning a full development RAD environment too :) --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
RE: [DUG]: RE: Fixing the VCL (LONG)
Max Nilson [[EMAIL PROTECTED]] wrote: There are two main problems with marketing any Delphi component from our experience. One is that the time to properly document a component is fairly long, almost as long as it takes to write them. The other is in having enough time to spend actually marketing the component, that is, placing it on all the Delphi sites, sending news messages to the most useful places, trying to get people to link to your sire etc. Then you also need to consider the technical support costs as an on going thing for the company... All true, but it needs to be balanced against the potential gains that are available. Perhaps too few of us are prepared to really attempt to market our own components. You imply that you've tried it, though? Because Profax's focus is on products rather than components it become very hard to justify this kind of money for the pitiful returns that can be achieved. We are open to offers to handle the documentation and marketing for us from anyone who can provide good references in this area. Ok, well I can't help you there - we haven't published any components ourselves (who has, on this list? How successful were you?). But, correct me if I'm wrong, I think there is a very large and potentially very lucrative market out there, not just "pitiful returns"... After trying a couple of the major component libraries, and accessing many of the shareware code our opinion was that most of the Delphi components available were just not good enough. It can be hard to sort the find the wheat among the chaff sometimes. But when you find a decent component it does make it worthwhile. Similarly, I think that only those who do publish decent components make money out of it. As I mentioned in my first message most of the third party components are just incremental improvements on the existing Delphi components (and so inheriting all of the default Windows control stuff that we don't like), or are wrapping some Windows control better or differently than Delphi does. As the Profax teams primary contention is that the underlying Windows controls are bogus enough to warrant replacing the 99% of the third party stuff is not much use to us. Well if you can't abide the standard Windows controls then you do have a problem: you're using an operating system you don't like. I'm not very fond of Windows myself, but I'm not quite so ambitious as to attempt to supersede all of the underlying Windows controls with my own versions! I think you're aiming higher than the average developer, so I can only wish you luck... Now in if two weeks I can implement an entire new data-aware grid that has more features, less bugs and is smaller and simpler than anything else out there then we regard this as *saving* money in the long run. We *want* to be able to maintain the code in house, because that means that if (Zharquon forbid!) a customer find a bug, then we can fix it instantly and not have to worry about mailing component authors (who may or may not do anything), maintaining patches on other people code and hideous versioning problems next upgrade. Ok, to some extent I agree with you. It sounds like this grid was well worth developing - if you were to develop something all-singing, all-dancing that you expected to take a lot more than two weeks, however, and can find something out there that already does a substantial amount of what you want then you can hardly say that you're better off developing it yourself. Or certain people wouldn't have had to switch to programming C++ now... :) Now I'm not 100% against third partly libraries, but our experience so far has gone like this: Infopower 2/3: Just wraps existing Delphi code (and badly in my opinion), has so many bugs and warts that we gave up trying to fix them, and the code after being hacked over and over from Delphi 1 - 2 - 3 - four is so cluttered as to be almost san scrit like. QuickReports 1/2/3: After fixing dozens of bugs, and notifying the authors )and getting no response or fixes in new code!), and running into terrible design flaws we gave up. AdRock components: Again just wrappers extending existing Windows controls. Inherit all the behaviour we don't want. All of these products now sit mouldering on our library shelves and will never be used again. The only two third-party products that we actually do use are: RP Pro 3: Gets the thumbs up for good coding, responsive developers and a perfect feature match for what we wanted to do, that is automatically generate reports because actually writing reports that a good component could write for you is the most boring, time wasting and costly exercise you will ever encounter. IB Objects: Jason Wharton provided a very nice connectivity layer to Interbase and we worked closely with him to get it working perfectly. Jason has now wandering off into doing custom component development on top of the connectivity layer so we as getting tempted to do a rewrite of the low levels of
RE: [DUG]: RE: Fixing the VCL (LONG)
Carl Reynolds replied to me: Well if you can't abide the standard Windows controls then you do have a problem: you're using an operating system you don't like. I'm not very fond of Windows myself, but I'm not quite so ambitious as to attempt to supersede all of the underlying Windows controls with my own versions! I have to point out here that my issues are with the standard Windows control types, not with the actual OS itself. I'm quite happy with the kernal, the GDI and most of the Windowing and event handling code, its just the existing controls that are weak. Strictly speaking we have only replaced the standard EDIT control and created a replacement for Delphi's grid. Other candidates for replacement are the page control and the tree view, and these are really low priority. But once we replced the standard edit control with a component that duplicated all of the functionality (caret, keyboard, drawing, selections, cut'n'paste etc) we could then start to extend this is all sorts of fun ways, and for little cost. This also allowed Ian and I to engineer some more elegant handling of the data-aware code so that the same control can switch from data-awawre to non data-aware with a tiny cost, and the validation and formatting were more under our control. I think you're aiming higher than the average developer, so I can only wish you luck... I am certainly not the 'average' developer! And with Delphi to play with I can aim extremely high and hit those targets. Our own components suffer from similar problems - among the things they expect is descriptive information of each database to be obtainable from tables within it, and they also rely on our own memory tables. So perhaps I should yield the point gracefully! :) Indeed 8-). As soon as you start concidering elegant meta-data handling you really need to start building additional stuff. This is one are that the Delphi designers left some what bare. And thats my primary contention, that as soon as you want to achieve real RAD development, and leaverage all the meta-data, business knowledge and special features in a database engine, the basic Delphi components are not just not good enough and custom component development is almost a necessity. Cheers, Max. --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
RE: [DUG]: RE: Fixing the VCL (LONG)
Max Nilson wrote: I have to point out here that my issues are with the standard Windows control types, not with the actual OS itself. I'm quite happy with the kernal, the GDI and most of the Windowing and event handling code, its just the existing controls that are weak. Strictly speaking we have only replaced the standard EDIT control and created a replacement for Delphi's grid. Other candidates for replacement are the page control and the tree view, and these are really low priority. But once we replced the standard edit control with a component that duplicated all of the functionality (caret, keyboard, drawing, selections, cut'n'paste etc) we could then start to extend this is all sorts of fun ways, and for little cost. By replacing controls such as the edit control you are alienating yourself from automatic updates if Microsoft ever changes or updates the way those controls work. In the near future Windows 2000 will be out and there may significant changes to the user interface (unlikely - but there may), and years down the track the user interface (or the logic behind it) may change again (for example if it ever goes over to 64bit). Programs written using the Microsoft components automatically gain any advantages provided by new versions of those components (such as an updated comctl32.dll) whereas your replacement controls will still be doing the same old same old. This is perhaps a non issue for simple controls such as the edit control (simple as in useage, not as in sound implementation) but with such wonders as tabbed notebooks etc this can be more relevant. Although I must agree with you about the standard Delphi grids. Just my 2cents worth. Phil. [EMAIL PROTECTED] --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: RE: Fixing the VCL (LONG)
By replacing controls such as the edit control you are alienating yourself from automatic updates if Microsoft ever changes or updates the way those controls work. In the near future Windows 2000 will be out and there may significant changes to the user interface (unlikely - but there may), and years down the track the user interface (or the logic behind it) may change again (for example if it ever goes over to 64bit). Programs written using the Microsoft components automatically gain any advantages provided by new versions of those components (such as an updated comctl32.dll) whereas your replacement controls will still be doing the same old same old. This is perhaps a non issue for simple controls such as the edit control (simple as in useage, not as in sound implementation) but with such wonders as tabbed notebooks etc this can be more relevant. Another way to look at this is, what happens when MS break the current controls - which they do with alarming regularity? Remember the ImageList problems??? From what I have seen on NT5 (beta 2 and B3 RC0) it is not that much different - for UI controls anyway - than 3.1. NT4 is pretty much no different, just a few new ones. yet another way to look at it is, if they change them and your customers need them, build them in! If MS changes theirs, and it breaks your app, you are going to have to do a rewrite (well, some of a rewrite) anyway. Just my 0.02c. N --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
Re: [DUG]: RE: Fixing the VCL (LONG)
Just my 0.02c. With all of the donations we should have enough for Friday drinkies by now. With everyone so up in arms about shortcomings of the VCL why do we not start an open source project at delphi.org.nz... Discuss a class hierarchy and methodology and begin to provide functionality to replace the vcl... We have a number of people from a fairly wide usage of Delphi, we should be able to implement everything from stream compression and encryption toolkits to UI replacements/extensions to communication tools. I'm aware that not everyone will participate evenly but look at it as the perfect teaching mechanism and a way to drive up Delphi popularity in New Zealand. Place a copyright that states any commercial usage by an offshore development firm results in a registration fee to cover increased traffic on delphi.org.nz... It's worth a crack... -- Aaron Scott-Boddendijk Jump Productions (07) 838-3371 Voice (07) 838-3372 Fax --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
RE: [DUG]: RE: Fixing the VCL (LONG)
-Original Message- From: INTERNET:[EMAIL PROTECTED] Sent: Thursday, 11 March 1999 22:22 To: Multiple recipients of list delphi Subject: Re: [DUG]: RE: Fixing the VCL (LONG) Good Idea, I have been slowly encapsulating the date/time functions into a type (ie rap all the date and time functions into one type so the code completion reduces my typing and assists my failing memory). The plan was to extend it to have true julian Date/Time component with Pope Gregory calender adjustments built in. Currently derived off this is a tDairyDateTime which adds the date encryption for the dairy industry. Not as exensive as a new/replacement Tedit but everyones 2c could add up to a big party and less reinventing for everyone. From: [EMAIL PROTECTED] Just my 0.02c. With all of the donations we should have enough for Friday drinkies by now. With everyone so up in arms about shortcomings of the VCL why do we not start an open source project at delphi.org.nz... Discuss a class hierarchy and methodology and begin to provide functionality to replace the vcl... We have a number of people from a fairly wide usage of Delphi, we should be able to implement everything from stream compression and encryption toolkits to UI replacements/extensions to communication tools. I'm aware that not everyone will participate evenly but look at it as the perfect teaching mechanism and a way to drive up Delphi popularity in New Zealand. Place a copyright that states any commercial usage by an offshore development firm results in a registration fee to cover increased traffic on delphi.org.nz... It's worth a crack... -- Aaron Scott-Boddendijk Jump Productions (07) 838-3371 Voice (07) 838-3372 Fax --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
