Yesterday my long time good friend and colleague Richard pinged me with a weird looking web address: www.embarcadero.com

When receiving such an address, there must be a reason... could it have some funny jokes or ahrm... pictures... in it... Richard usually dont send such links to me.. (hmm... I wonder if he keeps those to himself  .....Just kidding ). So it had to have something to do with what we do.

The name itself didnt ring many bells to me... but that can be because I have been living under a stone for a couple of years coding. Anyway.. I clicked it.

While the web page builds up I notice.. hmm... there is a cool tool... and there is another... but what have that to do with me or us?

Then suddenly a text written in relatively small font showed up... Embarcadero have bought CodeGear...  a few secs... WHAATT!!!! Is this April fools day?.. checking the calender... and year... nah... its indeed just any other normal day.

First impression were... a tools company not much different (although slightly bigger I admit) than us, bought CodeGear! How on earth can that happen. The mouse ate the elefant. We are DOOMED!

Well... then it was time to a second go on what exactly was Embarcadero (couldnt they have named it something pronounsable?.. and writable...my fingers are making knots trying to type it ).

Reading over what it was all about, then it shows that Embarcadero is a relatively big company, actually people wise bigger than CodeGear (but they have certainly not being making any fuzz about that in the media Im reading), and whats more important is that Embarcadero is just one of several private companies owned by a huge private investment company. Hence we are suddenly now talking about money backing of proportions that would make Borland have wet dreams in night.

Ok.. money and size isnt an issue anylonger... but what about the longevity of the CG tools? Could it be a shark attack that results in some technologies being digested and put into other tools, while the rest is discarded?

Only the future knows how it fares, but it certainly do look like Embarcaderos and CodeGears toolsets are extremely complimentary with no direct overlap at all, which indicates that there is a true potential for huge synergies between the companies. They have alot of dedicated and knowledgable developers, and we all knows that CodeGear have the same but on other type developer oriented projects.

Embarcaderos have an organization that contains all the relevant functions for running a developer oriented company, while CodeGear probably have been somewhat amputated in the seperation from Borland, and I could imagine that some administrative and marketing functions within CodeGear either were missing or at least severely limited in manpower. In that scenario, those areas would be naturally strengthened by this acquisition.

As Embarcadero have been targeting a very different vertical market than CodeGear, they also have their feets inside some places where CodeGear would never before have had access, specially related to native development (example Java houses and other non typical areas for CG native tools. Visa versa, Embarcadero now ofcourse have easier access to the many dedicated supporters of CG products, and this way will expect increasing sales of their own products. The total market for most people like us.. 3rdparty tools developers, does seem to open up as the market canvas have now been broadened and the exposure of our products potentially made alot more visible in usually non accessible places.

That should bode well for CodeGear customers too. If the market canvas grows, the potential to earn money for vendors targeting that canvas grows and that ensures stability and progress towards CodeGear customers.

My current take on the situation is that, despite the initially surprising selection of buyer, this is probably the best possible outcome one could dream of.

So ... Very welcome Embarcadero!

I think we all will have a great future together. Delphi, JBuilder, C++Builder now have both the code quality and the market canvas and exposure to really make things happen!

(I will try to get used to writing  "Embarcadero".... but boy... CodeGear is easier... will probably have to use the shorthand writing of it... CG vs ET... battle of the galaxians)

I have seen the light.. I have faith!

Kim Madsen
TeamC4D

Delphi 2010 has now been released by Embarcadero.

First impressions is, that if there have ever been a time to drop Delphi 7, and move on to a new Delphi, then that time has come.

D2010 is just so much faster than the last several Delphi releases, that its an absolute joy to use. It also have Delphi 7 usability features implemented, like the ability to get the old component bar back, as an alternative to the newer style component palette implemented in D2005.

There are few quirks related to that (like that the componentbar's position seems to move after a restert of D2010), but they are relatively minor issues, and can probably quickly be resolved in a future fixpack.

 In D2005, D2006, D2007 and D2009 there were nasty leaks in the IDE, that made the memory usage swell up over a short period of time, making the IDE (and the rest of the machine) painfully slow to use after a short while. Although some progress was made from D2005 to D2009, there still were annoying leaks of this type, that required a restart of the IDE regularly to get rid of the leaked memory.

Im happy to conclude that they finally nailed the leaks in the iDE in D2010 it seems. Previously it wasnt possible for me to work, using a complex project, for more than a couple of hours without having to restart Delphi. Now its not an issue any longer.

The responsiveness of the IDE has improved vastly. Its startup time seems quicker than D2009. In general it just has the right snappy feel about it that we knew from D7 (on the machines of that time), and that makes it a pleasure to use.

There have been improvements the components provided with D2010, but the, in my opinion, most interesting one is the new gesture support. >Gesture support means that you can make special mouse movements to signal a command to the application. That of course is mostly interesting when you are not using the mouse, but instead a touchscreen. Hence its possible to make an interface that operates similarly to the touchscreen of an iPhone.

I think its an important feature, not so much of the feature in itself, but because it gives some indications of where the desktop part of Delphi is heading or at least where it, imo is supposed to be heading.

I have, in a previous blog post, almost written off Delphi as a futureproof and viable development tool and language, due to the fact that for desktop applications, development tools like Adobe Flex and MS WPF are making serious efforts in providing a relatively easy to use way to make very cool looking client side applications with lots of functionality. Delphi simply lacked the facilities they are providing.

And on the server side I wrote off Delphi, as its market has been shrinking seriously due to Java and .Net and due to the loss of the last cross platform compatibility feature (namely cross compiling for .Net) which in addition to the previous loss of Linux support, by dropping the ancient Kylix compiler, really didnt leave many reasons for a manager to choose Delphi vs the rest of the wolfpack. The only major sellingpoint, one source/multiple platforms, that Delphi did have with Kylix 3 and Delphi.Net, wasnt any longer. Thats still the case today, but Embarcadero have however, within the last 6 months, announced plans for supporting cross platform compilation for Mac and Linux, which absolutely is a step in the right direction, as long as Embarcadero delivers on the plans!

Delphi 2010 is no doubt the best native Win32 development tool today. It runs circles around all other development tools in that respect. And if thats all you need, then there is no reason not to upgrade to D2010 right now!

With the new gesture support and plans for cross compilers, my griefs seems to have been heard, and Delphi may in the next years, actually have a chance to compete and win back market shares. However we still need to  see the cross compilation support emerge, and Embarcadero should not rest on the laurels about gesture controls, as that is just a small, but important, step in the right direction for desktop applications.

Whats imo missing on the desktop for Delphi to really compete? 

• Improved binding of any data to any control. Today the only binding existing is when you use specialized datasource binding aware controls (TDataSource and the TDBxxx components). It was cool when it was presented back in the early days of Delphi, but today it has been surpassed by both .Net and Adobe Flex/Flash 4, which allows for 2 way binding of any property to any other property or value. The existing Delphi DB controls needs to be deprecated, and somewhere in the hiearchy between TObject and TCustomControl, there needs to be added advanced automatic 2 way binding on any property value.
• The existing TCanvas and windows Device Contexts, should be abstracted further, to make it possible to place any control on the canvas, and let the canvas be free floating in a 3D space.  That would allow for a new ball game of user interfaces, which is allot more intuitive to how users perceive the world, than the current 2D flat way. One example... you only have so much screen estate available, and you want to present details about multiple products in your product inventory software at the same time. You would often resort to a list, and someone clicking on the item on the list to present a window with details about the product, or you would have a number of tabs with product information in each. However in both cases you dont actually present information concurrently about multiple products. What if you could use the Apple CoverFlow method (http://en.wikipedia.org/wiki/Cover_Flow), where the focused product is shown in a 2D way, while the other products full product information is shown as pages in 3D space. Then combine that with the gesture control and a touch screen, and let the user use his fingers and hands to navigate thru the products. Its allot more demanding on the hardware than a simple 2D form, and it would have been a challenge in the D7 days, but today, even the simplest machines PCs are able to provide enough power to make it look smooth.

Generally as language features I would like to see 

• XML and regular expressions as part of the language itself! XML has come to stay, and regular expressions are really very useful string matching and parsing facilities, that many applications use. But today its all done outside the language, via class instances etc. Why not simply make it part of the language syntax? Like you have a string native type, have an XML native type where you can simply do this: var myXML:XML = <xmlnode><xmlnode2 attr1="abx"/></xmlnode>; In fact check out E4X EcmaScript for XML (http://en.wikipedia.org/wiki/E4x), where they have chosen to integrate XML directly into the language. It seems so natural to use it that way, and much easier than going thru rigid object instances and collections. 

In addition, I think it wouldnt hurt, if they bright people of Embarcadero, would start to think about how to solve the following tasks as an integrated part of the development process:

• Packaging and distribution of applications. Today thats something that is made AFTER the application has been developed. Instead the IDE or language, should encourage that to happen while the development is taking place.. possibly by using the new attribute features of D2010.
• Distributing to the Win32 environment today is already quite complex, although made somewhat simpler by various 3rdparty installation tools. But the problem with most of them (if not all) is that they require use of yet another development tool and language for creating the relevant installation scripts. And those scripts of course very quickly become stale, and needs constant updating.
• Documentation has become part of the development process to some extent, by providing various comment tags inside the source code where the full document for a topic can be written in. Its a method I personally dont like as it clutters up the source immensely, but I also dont like the current alternative which is a completely decoupled documentation application, that needs to be kept in sync. Hence imo, the IDE should provide a solution that keeps things guaranteed in sync, but separates the documentation from the source, so its easy to get documentation translated to other languages, and its possible to distribute documentation and source separated.

I am seriously worried! Wake up call!

I perhaps should be worried about peace on earth, financial crisis, cost of energy, climate changes... and indeed I am... but thats not whats on my mind right now.
Whats on my mind is that Im seriously worried about the future of my beloved programming language Delphi. Since 1995, I have used Delphi extensively. Since 1998 I have contributed to the Delphi community via various projects. Since many years I have been a Borland/CodeGear Technology Partner. In other words, I have been living Delphi, breathing Delphi and dreaming Delphi... (sort of...).

I have been following Borlands rollercoaster ride with Delphi being the rising language, setting the standards for how to program, thru the very, for Delphi and the community, unfortunate (lets call a spade a spade... stupid) decisions that Borland have made over the years. The constant uncertainty about the direction of Delphi. The rise of cool technology which gets to some level of adoption, after which its being dismissed from one day to the next etc. It certainly have been a ride where one have had to have a certain stamina and to some extent, naivity and optimism to stay on board.

After these initial mind travels, I think its in place to wish RemObjects congratulations with their agreement with CodeGear about the new CodeGear/RemObjects joint project with codename Prism. What is Prism? Its also called Chrome and later renamed to Oxygene. Its an Object Pascal variation designed from ground up for the .Net platform. It contains alot of cool features, not found in Delphi today. Because its close to being a 1st citizen development language on the .Net platform (programming language wise I would consider C# the only true 1st citizen due to the direct ownership and management by Microsoft that 'owns' the .Net platform), its also able to integrate with all the new cool features of the .Net platform... nearly anyway. Its using Visual Studio 2008 as the IDE. Actually I think its really something of an impressive feat by the RemObjects guys to lift this project to the level it has reached today.

Hence, despite RemObjects and C4D's rivalery on other areas, I clearly recognize the technical merits of their product Oxygene.

So all that aside, get to the point old man!

What have historically made Delphi a development tool of choise (the list may not be complete, add your own reasons)?

• Fast one pass native code compiler
• Good debugger
• Integrated debugger, editor, compiler and designer (RAD)
• Good structured language
• Good backwards compatibility between releases
• Generally well designed control and component framework (Visual Control Library - VCL and RTL).
• Good price point
• Very good community support
• Not really any other development environments out there with the same featureset and usability.

In addition, slightly later in history, further reasons made it compelling to use Delphi:

• One source Linux support via the product called Kylix.
• One source .Net support via the product called Delphi/.Net.
• One source Win32 support via the product called Delphi/Win32.

Hence people started out with Delphi on the Win32 platform and some eyed an oppertunity to move their applications or components to other platforms as they were made available. Even today some people use Kylix as the development tool to delivery their applications to the Linux platform, many years after Borland made yet another stupid (spade=spade) move.... to discontinue the Kylix project.

Later Java and specially Visual Studio.Net have made serious ripples in the RAD development waters, blurring the originally apparent advantages and image of Delphi. Both have gained alot bigger market shares in the corporate environments than Delphi ever had. Specially Java has been able to (to some extent) replace existing mainframe oriented programming paradigms.

On the desktop, new requirements related to graphics, 3D, animations and the user experience are constantly rising. These are areas where specially Adobe's Flex and Flash RIA solutions have gained a very strong foothold. A foothold I doubt even Microsoft will be able to seriously dent. JavaFX, Silverlight and WPF are technologies also competing in that area. And our beloved Delphi have very little ammunition to provide there, except for relatively disconnected 3rdparty component providers trying to provide some of that functionality in the Delphi environment.

So to sum up the situation.. Delphi has lost foothold in the Win32 desktop space. It has no foothold in the Linux desktop space. It has no foothold in the Apple desktop space. It also have no foothold in any mobile spaces. Further it has lost whatever foothold in the server arena, where it has never been really really strong, partly due to conservatism and later 'Noone is shot if a project fails when one have chosen IBM, SUN or MS for the platform/development tools'.

So whats left? Mostly small developers who still have the freedom to choose according to their hearts rather than their wallets or corporate policies.

If corporates want to develop new projects for the MS platform, what will they choose? C# is most likely the answer.

Will corporates choose to develop native Win32/Win64 applications for new projects if they know those are going to reside on the MS platform only? Most will probably not. They will choose to use .Net due to the hype and the maturity of the platform.

Hence Delphi's iceflake is really melting rapidly from all sides. And that sentence is the trigger for my now almost complete loss of faith in the Delphi environment as a future proof platform.
CodeGear may have chosen a superiour compiler for .Net by hooking up with RemObjects, but they have also ensured that all existing projects and components that have already been made available for Delphi.Net on the .Net platform now see no future with Delphi. If they want to exist on the .Net platform, they only have the choise to use Prism/Visual Studio.Net ... or C#/Visual Studio.Net. The safe bet is to use C# as it, without doubt, will be the most up to date development language for the .Net platform for as long as MS decides that the .Net platform have a life.

Net result is thus that existing Delphi developers, who have played on the horse of cross platform support using single source, now have to choose to create multiple source trees, or simply to go where the cake is bigger and the current new technology emerges from. And thats not in the native Delphi world.

I have said it for years... Delphi's absolutely biggest advantage was the feasibility of RAD cross platform deployment based on single source, and the originally very vast developer and 3rdparty vendor community supporting the product.

CodeGear have essentially chosen to cut the legs off Delphi or put differently, to put a flame torch to the ice flake on which Delphi stands.

Not providing single source, multi platform support, equals dropping the one single feature and unique sales point, that made Delphi stand out these days, and that could make small/medium sized corporations think twice before jumping in bed with C#/VS.Net or Java.

Its unfortunately a very depressing outcome, and not so full of optimism and joy, as many previous blogs about CodeGear, that I have made.

Cross platform, single source .... cross platform, single source .... cross platform, single source .... cross platform, single source .... cross platform, single source!
THAT WAS YOUR UNIQUE SELLING POINT - EMBARCADERO/CODEGEAR!

/Kim Madsen

Warning... the following may contain provocative statements and irony.

There are often a reference to a programming language to be 'outdated', and often that happens in comparison to another language that someone wants to
promote.

Say.. Delphi... many places management and project managers refer to it as outdated.

But what exactly means 'outdated'? Why is something 'outdated'?

Looking strictly at the wording, then Java is more outdated than Delphi, as Java was invented in 1991 based on a C syntax, and Delphi in 1995 based on a Pascal syntax.

And buzzwords like Garbage Collection was invented all the way back in 1959 when Lisp was invented. Heck even Basic had GC built in.. so that surely _must_ be an outdated feature! ;)

Then there is C, which C# and Java and C++ et all builds parts of their syntax on... that was invented back in 1972... must seriously be outdated... why on earth are anyone still using C/C++ to make operating systems, real time systems and other applications that are critical and where leaks and severe bugs are no no's as they have a huge impact on the use of the product?.. yes.. why on earth is that.... reflection... ah.. reflection..

What about the term 'reflection'....

Reflection is in its core the same as RTTI in Delphi (RunTime Type Information), but given a new shiny brand.
It was already available in Smalltalk invented back in 1970/71.. so surely that feature must be perfect examplified object of being totally outdated.

Hmm.. object... object...     object oriented... that word combination rings a bell somewhere... now... we all know that C# and Java are masters of OO... anyway so are the claims... but did they invent OO?... nah... we all know that Bjarne Stoustrup invented C++ and the object oriented scheme dont we?..

Nope.. not even close. It goes all the way back to 1960s, and the language Simula that was invented by a couple of Norweigians.

So OO is really pretty old stuff.. it cant be useful today that old stuff can it? It must virtually be outdated!

That rings another bell... virtual... virtual.. something that isnt there for real!... weird word... ... virtual machine.. thats really a buzzword in this decade... What is actually referred to are process virtual machines. Things that enables on the fly interpretation of semi compiled source code (also called Pseudo code or P-code). Interpreter... that goes all the way back to 1930 (and perhaps even longer) by a numerical interpreter by IBM... THATS old.. so we wont even spend a startrek second more on that.. that is definitely outdated.

However there is another variant of process virtual machines, that use a technique called Just In Time compiling (JIT).. ie. the source or semicompiled source (P-code) is compiled to machine instructions shortly before the time the instructions are needed while executing the application.

THAT sounds cool... it MUST be a novel and very modern thing since it even got a modern name for it... Managed Code, right? Nah.. VisualWorx (which is a SmallTalk implementation) did that almost 30 years ago... in the 1980s. Thats old! Thats outdated!

Well.. you get the picture I hope...

What imo should be outdated is how money controls hype that controls management that controls pure logic and common sense.

Lets take a step back and discuss what exactly what is the reason for new commercially popular languages today?

My take is that its not technical, practical or even (for the single user) economical reasons that is the reason for them.
Its a global battle about marketshares and control. In other words... something happening in the very high altitudes where the air is so thin that people living in such places will get problems thinking rationally.

Kim Madsen
TeamC4D

We had on our newsgroups at news://news.components4developers.com recently a question about if kbmMW can be considered a 'corporate product'.

My answer to that was that in our opinion, yes, but we certainly dont have the marketing muscles of the big ones that are considered 'corporate'. I consider something to be 'Corporate' if the following conditions are fullfilled:

1. It serves a corporate purpose
2. It provides a reasonable ROI
3. It is backed by a stable organization/vendor
4. It has a future
5. It is maintainable
6. It is maintained

Lets take them one at a time:

1) Well.. if it doesnt serve any purpose in corporate sense (eg. a company cant use it for something useful), it isnt corporate.
2) If it is costing an arm and a leg to install or use to serve purpose 1, then it isnt corporate.
3) If its looking like abandonware, or anyway highriscware, then it isnt corporate. A company has to be able to trust that the vendor is around to support it.
4) If the product do not have a future, its not corporate. There is no idea for a company to spend energy on something without a future.
5) If the product is next to impossible to maintain and require too many manhours, its not corporate.
6) If the product is not maintained it means that the product is reaching a status that would kick in point 4. No future. Its not corporate.

In reality I see large corporations use products that they consider corporate, but that typically do not live up to those 6 criterias. Lets look at some examples:

Sun - J2EE: For the most part it doesnt live up to the 2nd and 5th criteria. It is typically difficult to get to perform (why there are lots of highly paid contractors in that area), and its equally difficult to deploy an application server. Some vendors of application servers have made it somewhat easier than others, but the base line is that a scalable, performing production deployment is not easily made.

Sun - JMS: In addition to the difficulties in deploying a production system, thus violating point 5, it also violates 2 as JMS by itself does absolutely nothing. Routing mechanisms, request/response mechanisms, quality of service mechanisms etc. must all be handcoded by each project wanting to implement JMS. There exists frameworks based on JMS that makes this somewhat easier, but that may actually end up in making the maintainability even worse.

Microsoft - VB: The number of VB3-6 applications still running in corporate environments are quite staggering. However it is abandonware, and no longer maintained by MS, hence violating 3, 4 and 6. In addition upgrading in the good old days from one VB version to another usually required rewriting specially the database access code as MS had an idea to reinvent the wheel on a 6 months basis.

Microsoft - .Net: That surely must be corporate, right? Well.. the corporations that based millions of US$ on VB in the good old days should actually have removed the 'Corporate' label of that product, although most havnt. The trackrecord (as in whats the chance your application can be recompiled with the next version) of MS development products except perhaps for Visual C/C++, has not really been something to make corporations feel a good warm fuzzy gut feeling. The amount of US$ spend to rewrite existing applications to move them to the new version or to support the new Vista etc. is simply staggering. People who believed in WinForms being the future also have to count with uncertainty to what amounts of rewrites are needed.

IBM - Visual Age for Java. It was actually a very capable Java development IDE, with some features that made it really unique. After IBM chose to drop VA for Eclipse, developers using VA had no choise but to follow to the new platform, despite that the new IDE didnt contain all the wizard functionality originally found in VA.

IBM - ComponentBroker. IBM's CORBA solution for Java and C++. It was dropped about 4 months after I attended a quite expensive course in the product. Fortunately we the company I worked for at the time didnt get to actually integrate it into something, but if we had, it would have cost serious US$ to replace it with something still maintained and supported. In addition it was cumbersome and errorprone to use it. However it was still considered 'Corporate' all the way until it was dismissed.

In my opinion, the label 'Corporate product' often is a synonym with big, difficult to use, difficult to manage, difficult to deploy, overly expensive software backed by the 3-4 most PR active IT companies.

What is your definition of 'Corporate'?

Kim

People who have registered on our myc4d portal or on TurboMiddleware now have access to a new cool freeware utility - kbmDiff.

As the name says, its a tool that can compare files and show you the differences. In addition it allows you to manually merge selected differences from one file to the other.

I cant take the credit for all the work behind it, as 95% of it was made by Angus Johnson as a demo for his TDiff component. I have however added several features to it like:

• Ability to compare normally non comparable files like unformatted XML (ofcourse using kbmMW's DOM XML parser/generator) and binary files.
• Scrollwheel support
• Support for clicking and dragging in the right differences summary pane to show where the difference is in the text

and some more details here and there to imo improve the user experience.

The application is actually quite versatile, and can easily be compared with the typical commercial tools in the market.

Angus Johnson, who deserves every credit, have a home page here: http://angusj.com/delphi/ where the original source code for TDiff and the TextDiff (as his project was called) can be found.

To get the kbmDiff version of it signup at: www.myc4d.com or at www.turbomiddleware.com

best regards

Kim Madsen

UPDATED June 14 2007 (check update further down)!

The last days another riot have happened in the CodeGear non-tech newsgroup. Yet again!

The relationship between a vendor and a consumer should be healthy. The vendor make decisions thats supposed to be for the benefit of the majority of its consumers and other potential consumers not yet in the fold. Sometimes those decisions are annoying some consumers or even hurting them to some extent. Hence the consumer ofcourse will need to voice his or hers opinion on whats going on and that its hurting the consumer. Thats a natural right in an open society with freedom of speech etc.

However there is a fine line between expressing ones opinions and terrorising the community. Disgruntled consumers are almost as dangerous as disgruntled employees... they can make alot of harm. The difference is imo however that the consumer often still have things at stake... existing codebases etc. and essentially often would have liked CodeGear to be successful of the simple reason that then the chance of the consumer to be successful with the current codebase is higher.

Hence its completely incomprehensible to me that all the so called Delphi lovers are so busy as they are damaging CodeGear by diminishing Delphi. Sure Delphi has had its rough edges in the D8 and D2005 releases, but the issues have been dealt with by CodeGear who obviously are aware about the problems and knows its in their interest to get those issues solved. Hence D2007 and Update 1.

Im personally quite annoyed about the way the critisism is expressed. Why do I care? Because I am a consumer of CodeGear products, and the company I work in is producing products consumed by thousands of CodeGear consumers too. Hence what damages CodeGear sales directly damages us and our customers. And I simply wont accept that, regardless of that Im in agreement with some of the elements that have been expressed by others regarding what would be good to have in a CodeGear roadmap like Linux/Cross compilation support etc.

The constant negative aura around CodeGear's non-tech group says to me that CodeGear is better of shutting it down permanently. Although sometimes being entertaining to read, its surely not doing CodeGear or its customers any good.

The article I wrote about a year ago 'The story of 3rdparty announcements and reactions on them' which is still available on our website at:

http://www.components4programmers.com/articles/thestoryof3rdpartyannouncementsa.htm

can be directly applied to whats going on between CodeGear as the vendor and its consumers.

UPDATE June 14 2007:

The responses I get on this blog entry, both as comments here and on the CodeGear nontech newsgroups, makes me realize that people dont seem to understand the effect that extremely negative posts in vast amounts can have. Its a misconception that just because its on a non-tech newsgroup, only the geeks will read it. WRONG. The non-tech newsgroup is being cached into several web based search machines, including Google Groups. Try to search for CodeGear and order the search by date.... the top 6 entries are all providing the probing potential new customer with a negative view on everything related to CodeGear.

Some people may be smart enough to read thru the bulls..t, but managers arent always that smart and as they may already be biased away from CodeGear, this number of negative posts will just be the final proof they need to convince their bosses that... "dont go the CG way... Ive read comments from their customers... and they dont believe in CG or its products... too risky to go there".

I welcome constructive discussions about features and techniques... but please.... grow up and dont act like a child when things dont go your way! As CodeGear have multiple times said.... single customers cant possible have any idea about why CodeGear make their business decisions the way they do, so continuing to whine about it wont do any good, on the contrare. No doubt that every community served by CodeGear, that being Delphi developers, C++ developers, PHP developers, Java developers etc. wants to feel that CodeGear takes special good care about them. However try to look at your own company... how does that operate? Are you able to provide specially good care for all your customers at once?... specially if the demanding ones are numerous? and very vocal? No.. .you will have to prioritize... and so does CodeGear.

Help yourself by helping CodeGear in the right way! Give them input but dont expect them to jump according to your tune as thats not how a company behaves. It receives the input, estimates the ups and downs of implementing the idea and then either accept, reject or postpone the idea. If you think you can do that better than CodeGear and being more economically successful than CodeGear, then you have an option for starting your own company. Do that... spend time on that... and realize how the world suddenly seems different when the problems and tough decisions start to pile up.

Kim

During the last several years, our flagship product, kbmMW, have been supporting more and more IDE's and versions, and it has also undergone a facelift in the sense that multiple editions were made available.

kbmMW currently consists of 2 packages (one runtime and one designtime) for each IDE for each edition. Each of those packages consists of one or two files. As kbmMW currently supports 10 different IDE's/variants (D5, D6, D7, D2005 Win32, D2005 .Net, D2006 Win32, D2006 .Net, D2007 Win32, C++ Builder 6, Kylix 3), and there are (or have been) 6 different flavours of kbmMW (OpenSource, Std, Pro, ProPlus, Ent, CodeGear), simple math makes the number of files to update each time a source file is renamed, deleted or added quite staggering. Its currently totalling around 100 files that must be updated!

That was starting to get REALLY boring to do, not to say time consuming and error prone. Automation must be the name of the day!

Hence we had to invest some time in a new product called kbmProject, which essentially is an advanced project file generator using scriptable templates.

In it we define:

• Units - which defines all the units that we know of for kbmMW as a whole. The unit definitions can also include information about forms/datamodules etc.
• Requirements - which define all the possible requirements that we know of for kbmMW as a whole.
• Projects - which we use for defining editions and what subset of the Units definition and Requirements they should contain.
• Templates - which defines the overall layout of the files. The templates can contain scripts and take advantage of variables/parameters defined on a job, project, template group, template, unit and snippet level etc.
• Template groups - which we use for defining groups of templates ... doh...
• Jobs - which is a combination of a Project and a Template Group

In addition we can define:

• Snippets - which essentially are small reusable code/data pieces that can be referenced from within a template
• Conditions - which for example can be used to indicate if a specific unit or requirement should be part of a specific package under some given conditions

When it all has been hooked up correctly, its as simple as clicking a Generate all button and all the relevant package files are generated automatically.

Quite neat!

This is a screenshot of the units pane... notice the raw unpolished look :)... its a good indication for this being a tool for toolers :)

And the following is a screenshot showing the templates and template groups.

As can be seen, the currently selected template simply contains a reference to the snippet BPK_kbmMW_Designtime. It could have contained alot more if needed, but I decided that I preferred the snippets to contain all the info as it would then be easily reusable.

So lets checkout the snippet then....

The snippet can be opened in a fullscreen editor to make it easier to read/edit.

Some places in this snippet there are references to either parameters or other snippets. The {%$=...} syntax references a parameter, and the {%$@....} references another snippet that will be inserted at that place.

The parameters can be defined on almost all elements in kbmProject. They are searched in a specific order to for example ensure that the parameter ANAME on the unit level takes precedence over ANAME (if defined) on job level etc.

The following show the scripted snippet SpaceLibsFroBpkPackage.

Anyway this was just to show you some of the extra tools we need to maintain continued development of kbmMW.

Kim/C4D