Ryan's Rambling

Saturday, December 01, 2007

Chris Bensen: Upgrading Delphi

It is always interesting (frustrating) following the upgrade/stick/switch turmoil that goes along with any consideration of moving from a stable devil you know tool versus the shiny new thing. Often the implicit upgrade cycle you would hope to happen is hindered by a slow release cycle on the tool of choice or lack of compelling features. These items have been beaten to death by others but I thought some personal insights from similar struggles I have seen may as well be added.

In any upgrade it is generally the "little things" that surface to haunt you so anyone that has been through a prior upgrade always entertains the idea that there are many of those gremlins just waiting for a chance to laugh at you publicly after you have deployed to your clients.

I participate in two significant products, one based on Delphi 6 and another still on Delphi 5. In both cases the volume of code, testing capacity, and potential re-platforming as are always cited as significant barriers to attacking the upgrade cycle. Due to 3rd party dependencies the latter project has an extremely high bar for upgrading. In both cases the problem is firmly rooted in not carrying out a natural and continuous upgrade cycle with robust testing. Until you have the "must have" in the new version you can't really afford to make the move. The business case simply does not exist and diminishes the further you get from the tip release of you development tool.

Rather than suggest you should not upgrade I think a pragmatic approach that I have found moderately successful is worth highlighting. For much of the server components of one of the products the code has been maintained in each new release of the Borland/CodeGear toolset but always back-compiled and tested using Delphi 6. So, all along the code was maintained in Delphi 7, BDS 2005, BDS 2006, and finally in RAD Studio 2007. That is great, after getting over the the initial hate for some of the IDE changes (SDI) you start to rely heavily on the new features like live templates, refactoring, code metrics, and models. Still nothing new is needed for the product that goes out the door though so upgrade sell is weak based on a "feature case."

But there are definitely reasons to upgrade. Recently, we were doing capacity testing and were a bit disappointed with our numbers and needed a quick hit. Without a single change to compiler options, code base, etc. we performed the same capacity testing with the application suite complied under RAD Studio 2007. We immediately saw a consistent 25-30% capacity volume increase. The majority of this is easily related directly to the the new memory manager (FastMM) and better inlining of key functions. Most of these items we could get if we were willing to alter the system to include or use 3rd party tools but the whole point was OOTB improvement. Since it was server-side code VCL changes really were not a factor.

We did not need the increased capacity immediately so we simply tucked it away in the "good to know" column. Had we needed it I am sure an upgrade on the server components would have happened right then (not a strong enough business case). We are now taking steps to assess a full upgrade on the client and server components and work out a process that will not leave us hung on an older version as we are now. What is the biggest hang up? Proper coverage for the testing. You can never have enough and dealing with tool related problems is never a good sell. An upgrade advisor tool that can run on a project would certainly be nice to have.

Over time though there has been a persistent set of issues that never quite seem to be addressed when you are trying to push a particular upgrade. Don't get me wrong, I am fully in the "upgrade often and stay upgraded" column but this list contains the items that most often leave me hesitant:

  1. Install Experience - What you get after you finish the install is great... but getting there is appalling and there is no amount of counter argument that can ever suggest it is acceptable. Most persons that have installed any recent BDS/RAD Studio have most likely installed other products that are equally complex. I can get through OS + Service Packs often faster than I can do the same for RAD Studio. Suggestions that this is an MSI (Windows Installer) problem only serve to alienate those who actually know that it isn't MSI, rather it is how it is being used. MSI may not be fun but it is often a necessary evil.
  2. Software Assurance vs Upgrade Cost - Upgrade costs always factor. The problem is they shouldn't, CodeGear has a fabulous subscription service called Software Assurance. While information about Software Assurance is more readily available these days it is still difficult to get your head around it and why it makes so much sense. Make subscriptions the only sales model and show clearly how your frequent release cycle makes this a cost benefit. There are blogs and even calculators out there that demonstrate this but "direct from CodeGear" means something.
  3. Difficultly in showing the big benefits - The integration of dUnit, nUnit, MS Build (hmmm, wanted NAnt myself), FastMM, for each looping, code metrics, refactoring, generics, live templates... the list goes on and anyone following along with the upgrades is inherently aware of them and enjoying them but each of these is small by itself and information on them is more often found in blogs or secondary sources. These factors all play into quality and effort reduction improvements in our own projects in terms of quality, defect rates, and performance. The leading question is how do you turn that into a strong business case. The sales pitch "have less defects, more developer time, and a faster more robust product" may exist on the CodeGear site but I haven't seen it.
  4. Documentation - Having used Delphi for so long I can't really appreciate the documentation woes that exist but on the occasions I find myself hunting for something in the help I realize just how difficult it can be for an OOTB experience. The help has been improving in first-use and correctness with each release but in some ways is still not on par with Delphi 7 and earlier releases (the language guide is still hard for me to locate to this day). The "little things" kill you here. Try finding the list of VERxxx compiler defines... (tell me if you find it).
  5. Features only beneficial on new projects - ECO... everything I have seen and played with suggests this is a great addition to Delphi but the fact remains it is similar to re-platforming when it comes to making use of it. Give me MAC's, 64-bit, Unicode and even CF. These are core improvements I can use on products that have hundreds of man-years invested.

In the end the Delphi product is targeted at developers but the install process is so burdensome that it is difficult for a business application developer to potentially have to spend time on assessing and using the tool when the install experience takes up valuable time and leaves the wrong taste in the mouth and leaves little for a concrete experience in the software.

After all the non-positive comments above I still have to say that the upgrades are well worth the effort but that is more from the fact that I know the benefits are in there from constant exposure to them as opposed to looking at any given

information on the CodeGear site and going "Wow". So, if you have been hedging on upgrading I strongly encourage you to get past the OOTB experience and get used to the product. The benefits are there and your productivity will actually increase. You may even like the SDI interface after some time ;-).

Chris Bensen: Upgrading Delphi
Why aren't you upgrading Delphi- Reasons and myths

Labels: ,

Technorati: , ,

Labels: ,

Monday, September 17, 2007

MSN Desktop Search Delphi code

It was quite some time ago that I discussed an IFilter implementation using Delphi code. Here is the code for that blog post.

 

Source download link (v2.1)

Technorati: ,


Labels: ,

Labels: ,

Tuesday, November 07, 2006

Borland Drops StarTeam Standard and Web Editions

Well it looks like Borland will continue the pattern of introducing version control sub-systems that I like and then removing them from the line up after two or three years. It appears the Standard Edition of StarTeam does not meet with the Borland ALM direction so anyone using it can either move up to the Enterprise licensing or somewhere else. The notice indicates that version control is a commodity so I would expect they believe that anyone who thought that the standard SKU was satisfactory will transition to sub-version or some other free tool.

This is twice now that Borland has provided a version control solution with the Delphi license and then go on to drop support. Both times I was quite happy with the solutions and happily moved to them. TeamSource was a great small shop tool and I really liked the model and integration. I didn't mind switching to StarTeam either and had become rather attached to the great linking support and build tagging.

The problem with this announcement is that the it leaves StarTeam in an all or nothing (planned it would seem) position and if you already have the rest of the change request/ticketing/project management bits taken care of outside of the Borland suite of tools. So, the upgrade scheme isn't really going to fly with me :-(.

The documents that are linked below make no references to the status of StarTeam within the DevCo/DTG but I am sure something will pop up shortly.

Further reading:

Borland Support Newsletter October 2006
Borland StarTeam Standard Edition CR-only Sunset FAQ
Borland StarTeam Edition Sunset Customer Notification

Labels: ,

Thursday, September 15, 2005

Delphi 2005 Rollup Update

Allen Bauer has posted a rollup of his recent Delphi 2005 fixes. It is really good to see Borland rolling out these informal (read pre-beta) patches as they are being corrected in the next major release.

You should also head over to the Borland site to pick up the preview release of the compact framework support (compiler only). This is just what many of us were asking for and it is a great thing to see them deliver. I haven’t had much time to play with it myself yet but it is definitely on the list and I will be converting a smallish golf related applet over to it as soon as I can.

Kudos to the Delphi team for their devotion.

Labels: ,

Monday, May 30, 2005

Delphi and the Compact Framework, Real Soon Now?

David I posts about a preview they are showing at the SDC sessions. From the blog post it appears that we may very well see a preview compiler targeting the .NET Compact Framework prior to the next major release of Delphi.

While details are sketchy it is extremely positive to hear about the compiler showing up prior to the next major release. Hopefully we can do our bit and flush out any major platform issues as part of a preview so the next major release can have something robust and workable.

Some background materials:
My point of view
Danny's preview of Delphi on CF
Allen's follow up on VCL/WinForms positioning


Kudos to the Delphi team for pushing it out the door :).

This is probably a good time for you to pick up Software Assurance if you haven't already. After you figure out what it is it doesn't make sense to not have it if you are using any Borland Tools.

Labels: , ,

Saturday, May 28, 2005

Delphi and CaliberRM, getting an error

I was delighted to see the CaliberRM 2005 plugin being released (preview at least). However I had already downloaded and fiddled with the 5.1 SDK so I was left with a wonderful Unable to load Java VM specified in C:\Program Files\Borland\CaliberRM SDK 7.0\lib\CaliberRMSDK70.ini error message each time I tried to install the package. Pretty much the same thing I got when I wanted to try CaliberRM after having installed Delphi 2005. In my prior attempt I simply gave up. I continued on with my review of CaliberRM and must say that I really do like it (or anything like it). I tried it on a small project and the additional process and breakdown resulted in some extremely clear requirements being pumped out the other end. So, even within integration into the Delphi IDE I am impressed with the tool as a whole.

I figured the updated plugin would fix my problems... all it did was change the error message from the 5.1 SDK message to the 7.0 SDK message :(. Since my eval period is coming to a close I really did want to see it working in the environment. I tried reinstalling the SDK (well, a repair install on Caliber anyway) but that didn't resolve the problem. Since the SDK seems to be merged with the StarTeam SDK I figured I would start searching on that for some tips... StarTeam Support Entry solves the problem very nicely.

Now I can finally see if the integration is of any benefit :).

Labels: ,

Tuesday, May 17, 2005

Free Pascal 2.0 Released

For those interested in moderately compatible alternatives to Delphi you should definitely check out FreePascal 2.0 release. The compiler core has been rewritten and the beta versions I have played with seemed to work quite well. I was hoping to see Itanium support though :(.

Labels:

Wednesday, May 04, 2005

Cyclomatic Complexity for Delphi

I am releasing an internal tool for determining Cyclomatic Complexity of Delphi (or Pascal) source code. Cyclomatic complexity is a great way to determine the level of unit testing required on different methods in a class or module. It is an integrated tool in the Delphi IDE and supports Delphi 6, 7, and 2005. The wizard integration is something new so there might be a glitch or two - let me know.

Anyway, you can find out more on the CCP page.

Update: There was a bug when exiting Delphi if you had any ccp messages in the message view. An updated 0.9.1.2006 build and source are on the site now for anyone that downloaded the software already. You can confirm the version by right clicking on the bpl and choosing properties.

Labels:

Saturday, April 02, 2005

Quickly jump to Quality Central Items with MSN Desktop Search

In your MSN Desktop Search type the following into the search bar (without the quotes) "@qc,http://qc.borland.com/wc/qcmain.aspx?d=$w". You will get a message that the shortcut has been added. From that point on you can simply type "qc ####" into your search bar and it will faithfully open up a new browser window to that QC report.

Labels:

Monday, March 28, 2005

Delphi2005 and tlibimp

It appears the new type library import wizard is broken (or inconsistent). If you want to ensure you don't get component wrappers generated for a particular type library you should open up a console (dos box) and execute the following command "..\bin\tlibimp.exe -Ha- -Hr- -Hs- msxml4.dll" after having changed in the "\bds\3.0\imports\" folder. Change the library name and path(s) as required for your case.

As usual, you can edit the uses clause to remove the extra units that are automatically inserted (normally leaving only Windows and ActiveX are sufficient). This can be a benefit depending on your intended use as the compiled binary will have less dependencies and you can have a significant benefit on your binaries size.

Labels: ,

Saturday, March 19, 2005

Delphi.NET and the Compact Framework

Danny has provided an update on Delphi support of the Compact Framework. It all sounds very promising but...

For myself, and I would guess many others, we are being faced with a new challenge where PDA/Phone devices are much more prevalent to our solutions. In the past I have been very blessed by the hard work of the Delphi team to provide not only a top of the line visual tool for both client and server components but a complete tool that can be used for absolutely every need no matter how low level (only missing out on driver development but thank the gods I haven't had to do that). I enjoyed being able to easily contrast Delphi against VB, C++, and Java. If you wanted fast development, good maintainability, and robust software you choose Delphi. When it came to micro devices, in days gone past, it was easy to explain why alternate tools were required for Windows and Palm devices however with the broad availability of J2ME and .NET CF it is becoming much more difficult to continue to suggest that two skillsets are required to develop and deploy against these devices.

Without even marginal support for the Compact Framework Borland has, not intentionally, reduced Delphi to the position VB once owned for Win32 development. While VB has been available on micro devices for some time prior to CF.NET it was really a weak contender with extremely limited capabilities to actually use the platform. Using and supporting CF.NET gives Borland a clear chance to provide a viable alternative for long standing Delphi fans that are not greatly interested in a full scale switch over to C# or Java. If someone wants to suggest we don't have to consider the benefits of having only a single language their developers can support then they simply don't understand the cost savings and risk mitigation that are achieved when everyone in a dev shop can be tasked with code changes. The days when it was acceptable to keep a couple resources around for the C++/Java bits done on compact devices are gone.

What I am looking for from Borland is the ability to create and deploy applications to these devices. What I am not looking for are things like VCL.NET, advanced debugging support, and designer support. I would certainly take those features if they were offered but they are definitely not high on my list of needs. Having done development for Palm, Embedded VB, Embedded C++, and some recent CF.NET work I know that the most important capability I value is quite simply the ability to make it work on the platform.

Application servers, web clients, and full rich clients are still my bread and butter. Micro devices, while increasing in importance, still remains the candy to be offered as value adds to those primary services. The only thing I need right now is being able to target the CF.NET platform in if the methods are primitive.

So, if you want Borland to let you in the playground, rather than watching from outside the fence then head over to Danny's most recent blog on CF and let him know the things that you require most and that we need it sooner rather than later.

Labels: , ,

Friday, March 11, 2005

Delphi, Uses, IFilter, and MSN Desktop Search

It has been ages since I have posted anything and I have not gotten around to posting on some of the items I had in the queue but that will happen eventually.

I am sure many people are aware that the desktop search choices are coming out fast and furious. I have about 500K files/items on my local computer and I am definitely in the habit of misplacing a particular file often enough.

I hadn't bothered with the first Google Desktop Search (GDS) as it would not index content outside of a pretty refined set of file types. The recently released version corrects that problem and is a pretty small download. It does a much better job in what it will index and is extensible with some programming (using IDispatch based interfaces, tsk tsk). I am sure it will be a decent tool but I don't really have a high degree of trust in letting it into my Outlook data just yet. I have it installed on a Virtual PC to give it a test and play around with it. Since I use google as my mainstay web search it isn't a stretch to doing it on my desktop as well.

I have had the MSN Desktop Search beta installed since it was released. I simply couldn't pass on an opportunity to quickly search through my Outlook e-mail. The packrat in me has led me to having an archive policy set to six months and over the years I am up around 3GB of archived e-mail. Searching into those archives in a reasonable fashion is a dream come true. MSN Desktop Search does it both quickly and reliably. Searches against Outlook are incredibly fast and it hasn't let me down on a single search yet.

A secondary, although more often used, search need is grepping through the volumes of the source code (predominately Delphi). Typically I have stuck with the dos based grep and/or the Delphi editor supplied version. This works for many cases but the search speed certainly doesn't compare to what you find from either of the two search engines I have tried thus far. For code and html documentation libaries you simply can't lose by installing one of these search engines.

But... I want more. The MSN Desktop Search takes advantage of the IFilter interface that was designed for other Microsoft Search technologies such as Index Server and SharePoint (I am not convinced that the new search is anything other then a new face on an already pre-existing and robust technology). Using the IFilter interface permits you to use any existing filters that may exist such as the PDF filter that is linked on the beta download page. But, more importantly, it allows the addition of new filters that you can develop yourself for custom formats or specialized needs.

This was my first step into filter development so I started with something simple that would be of potential benefit to myself. I have many shared modules between many projects so a change in a particular module can have far reaching impacts. These projects can be old mothballed projects, up and coming work, and large efforts with many external dependencies that I need to watch for. Before, or more likely while, making some changes it is definitely an asset to initiate a light impact analysis to see any dependencies that should be watched for. So, to this end I figured a uses filter extension would be just up my alley. Since it involves parsing the Delphi source it also permits extending the search patterns to include searching for where classes and functions are used versus defined. Part of this is about just having some fun doing it versus building up an impact tool... good for helping with first guess estimates.

The uses filter parses Delphi source files, establishing the list of used units. Additional custom properties are added with the list as well as setting the standard keywords property with that list. This means I can execute a search such as "keywords:unit_name" and I am then presented with a list of Delphi source files that use that particular unit. This helps keep the search results short and usable since the words are not scanned in every e-mail, document, and text file floating around your local machine.

The picture belows shows a search that shows modules using two units at the same time. You will note that the named units are in the keywords properties (this also means we don't find units where the unit may have been historically used and may have been commented out, etc).



Delphi, of course, is the tool I used. After stumbling around for a while I ended up building up a filter interface file with the relevant declarations for constants, types, and interfaces. I then created a new ActiveX project and created the basic framework code with support for the necessary interfaces and stub implementations. Be an appropriately lazy developer, I decided to implement the filter as an extension/aggregate of the stock text filter the desktop search was using and simply tag my extra bits on afterwards. This means I wasn't losing any basic text search capabilities either. To this end, I was able to get the filter up and running pretty quickly with the help of the filter test tools from the MS SDK. Using Martin Waldenburg's excellent mwPasLex source code made accurately extracting the uses from the source files a breeze. After setting a few registry entries (see the MSDN IFilter for details) I was up and running with a working copy pretty quickly aside from the long re-index times required for good testing. The moral of that story is don't test on a machine with 500K files; thank heavens for virtual PC.


I am still testing and tweaking the code otherwise I would make it available on the site. If you happen to be interested in having the code (for any purpose) just leave a comment with a suitably spam-proofed e-mail and I will forward along the current version. I want to figure out how I can get the desktop search to respect my new properties for both display and searching. I didn't want to use the keywords property but all my initial attempts to get the search engine to use my "uses:" prefix simply failed. If someone knows how that works (not on SharePoint or Index Server) I would be quite interested since I think is where the real power resides.

Labels: ,

Thursday, December 23, 2004

Delphi 8 Update #3 - Fixes for .NET 1.1 SP

Well, it has definitely been too long in coming although I can understand they had other things to keep them busy ;-).

I am downloading it now. If you try to download I suggest you use the list files and then download the file contained in the zip. My attempts to download it through the download link just left me in a cicle of re-agreeing to the licensing agreement :-(.

Here is the link

Labels: ,

Tuesday, September 14, 2004

DiamondBack really moves some markers

The guys at Borland seem to have pulled out all the stops and implemented some of my most sought after capabilities. Specifically we have for ... in syntax (qc #6922), Multi-unit namespaces (i.e. real namespace support as we expect it) [Allen], and finally we will have function inlining support as well.

It does appear that Generics and.NET 2.0 support will be a post-release concern. Hopefully when the release comes out we will all remember that lots of positive movement has been achieved before we start complaining out the "other" new stuff we all wanted.

Thanks to Robert Love for blogging on these new features from BorCon.

Labels: ,

Wednesday, September 08, 2004

Great list of Delphi RSS feeds

Nick has put together a great list of Delphi related blogs. Check it out and add it to your reader.

Labels: ,

Wednesday, August 11, 2004

As always, more information, more questions

A very well written note regarding the next version of Delphi. I must confess to agreeing with the content. I am even pleasantly suprised to see Nick with some very good comments along the same vein.

To date, 90% of my work still keeps me in Delphi 6 with a few jaunts into D7 and virtually no reason to spend much time in D8.NET (not saying there is no dotnet going on...).

I don't know the answers but I know the Delphi language and underpinnings are an elegant solution that needs to be marketed and promoted in a manner that adequately highlights its ability to produce solid solutions.

Labels: ,

The Next Delphi :-)

A place to watch is the Borland Blogs and have a peek here. Apparently we will be feeding snakes for the next release ;-).

Labels:

Sunday, July 04, 2004

Short-circuit evaluation got me

Virtually everything we do is server based on XML services. The majority is custom XML messaging versus using SOAP (in many cases we can easily outperform the standard SOAP stack by a factor of 10-35%). We are in the process of upgrading one of our major services and the existing test cases are sitting in individual HTML pages and using the Microsoft XML components to submit the incoming data and the user visually compares the results to the displayed expected outcomes (not very automated but it derived from the development itself). We are performing a major upgrade to this technology and one of the areas that we wanted to improve on was in the automated testing area. We have over 130 test cases for this particular server and it really isn't enough but in order to engage the user we need something that is friendlier than html and xml with a smattering of JScript. Perhaps stupidly, I asked for this particular task since it is something I wanted to further on a more general basis for the rest of our services.

Hmmm, lots of background for a lesson about even old dogs get caught by simple things. I have been using Pascal/Delphi since tp5.

Anyway, I have put together a specialized editor to allow the entry of the test case materials broken down by category, procedures, and individual test cases. This data is all managed using XML and client data sets (which are perhaps one of my most loved Delphi features). I use that data to generate a test file in a format that the primary tool I created, the HTTP/XML test runner, takes as input. It is with the runner tool that I had a very stupid mistake (no one has seen it, so at least some face has been saved ;)).

Effectively, I need to loop through the structured data (categories, procedures, and cases) and I do it using a simple while loop while maintaining the pass/failure status. The root problem itself is that this is a command line tool and I wanted the exit code to represent whether failures occurred to support automated build/test processes. As such, the processing loops are contained within functions which return false in the event that any inner tests had failed. This was being maintained by the deceptively simple "Result := Result and ProcessCase();". Sure, that works, looks like it works, but it doesn't. While testing I found that the process would give up the ghost as soon as the first failure would occur but continue to appear to work, but no more test cases would be run (hmmm).

Hey, wait, my side effect, the call to ProcessCase(), was not happening. Well, a big DUH! Back to the grind and thank goodness for failing test cases at the right time.

Labels:

Monday, June 21, 2004

Small Optimization for Imported Type Libraries

When you import a type library in any version of Delphi it will generate a series of interfaces, constants, and wrappers. This is great but it will always place nearlythe same list of units in the interface uses clause. This will typically look like this "uses Windows, ActiveX, Classes, Graphics, OleCtrls, OleServer, StdVCL, Variants;" Depending on what you are using the imported type library for this list creates references that will bloat your application, especially if it is a server side program.

You can clean up this list by removing all but "uses Windows, ActiveX;" and the unit should still remain complete but you have removed many dependencies that you don't need. The resulting executable, if it isn't already dependent on the graphics and OLE support will be much smaller. On occassion, you will need to include OleCtrls if the imported control has events and you care about dropping the control on a form or data module.

Labels:

Thursday, May 13, 2004

A Delphi Solution for the 2rss Issue

Well, I have come up with a solution for myself with regard to the previously mentioned 2rss ad problem. Delphi + Irritated User = Solutions :-).

I spent a bit of time looking at the output produced by the 2rss feed and compared to what was available in the atom feed itself since that is all the www.blogger.com provides. It turns out that it is a really simple transform that is required and a few minutes of coding (in Delphi anyway) combined with an XSLT sheet solves the problem. For my personal use I have put together an ISAPI library to take any atom feed and turn it into the equivalent rss 2.0 feed. It works in the very same manner as that of the www.2rss.com tool but does it without the ads.

NOTE: This is not something that I plan to make available for anyone but myself. I simply don't have the bandwidth to allow arbitrary use.

Rather, I am making the source code for the library available for use under any terms. If you are interested you can pick it up here. If you are interested in using it you need an IIS server, MS XML 3.0, and Delphi 7 (very likely compatible with D5 and D6). If it is of use let me know and if you improve on it I wouldn't mind getting those updates back.

Back to some ad-free rss feeds ;-)

Labels: ,

Friday, May 07, 2004

Borland Delphi 7.1 Service Pack Arrives

The long awaited service pack has finally arrived. It includes a huge pile of fixes (but not everything). This is very likely the last update we will see prior to a combined Delphi 9 with both Win32/.NET support.

Pick it up here (and have your original CD ready)

Labels:

Wednesday, April 21, 2004

Namespaces for Delphi

Danny's Blog provides a good indicator that namespaces will get the notice they deserve. You will have to read carefully to notice it but it is there. I know I certainly can't wait for full namespace control for library packaging.I am not sure whether namespaces were on the radar in the past but I do suspect they were. I do know however that Delphineedsnamespaces before I will consider it a viable language choice for me in the .NET space. While you may still be able to get the job done without them it is important that you can properly contain the exposedAPI of any library that you use internally amongst many developers or when publishing the library to external developers.

In the same blog there is a mention of some refactoring work as well. I hope to see Delphi 9 hit the streets as soon as possible with some of these important new capabilities.Keep up the great work guys.

Labels:

Tuesday, March 16, 2004

Delphi 8 has integrated error reporting

Allen Bauer has provided a new IDE extension that permits the automated reporting of IDE errors to QC. This is great stuff and everyone should install it. It is quick and easy to put in place and should help out the IDE stability in the long run. I even got to send a report just a few minutes after installing it.

Labels:

Thursday, March 11, 2004

The Update is Here

See the links in the previous entry. The updates are there. I have downloaded them and just running through the install.

Labels:

Delphi 8 .Net Update #2 is just about here

Just to tease us the update page is there but the links are dead. Anders blog gives us the hint it should be there before the end of the day. We are getting both a full update to Delphi as well as a much improved help file.

Here is to hoping we have a really usable tool with these fixes.

Labels:

Wednesday, March 10, 2004

Blogging with a Delphi Tool

I got tired of using the www.blogger.com web page for adding new entries. It seems like by the time I get to blogger I have lost that quick little thought or link I wanted to post.I have built a simple little blog editor using the XML-RPC blogging API and Delphi 7. It just provides the basics with the IE DHTML editor control and allows me to easily manage my blog from the system tray (and no VB or OCX's in sight). It can only handle blogger (or more correctly I have only tested it with blogger) and will only deal with a single account but I like to keep it simple.It likely has a few bugsbut if you care to give it a try you can download it below. Comments are welcome. comment

QuickBlog (all files zipped ~ 900KB)

QuickBlog (single file zipped ~ 100KB if you already have Delphi 7)

Happy Blogging

Labels: ,

Tuesday, March 02, 2004

Delphi8 and Crystal Reports solution coming

Anders has noted a newsgroup posting that indicates that update 2 for Delphi 8 will include a fix for using the .NET Crystal Report solution. See the blog entry at the bottom of the page for the post by Danny Thorpe.

Labels:

Tuesday, February 10, 2004

Improving Syntax Highlighting of PHP in the Delphi IDE




I found a great use for the syntax highlighter stuff I was playing with last week. Nothing is better than having a legitimate use for something you did just for the exploration ;-). I have, over the past while been working with quite a bit of PHP pages as a front end to some delphi services. While I have tried out a few editors I am either finding I simply don't like them or more likely I am just too stuck in my editing patterns to want to use something other than Delphi for plain text work. Delphi 7 and Delphi 8 both include a stock PHP highlighter to make your life a bit easier but they are not really great. One of the pet peeves is that variables referenced inside strings are not highlighted :-(. This has caused me grief more than once.

A light bulb turns on (however dim it may be on any given day) and the revelation that I could use the stock PHP highlighter and simply aggregate it to add the extra syntax highlighting :-). It turns out to be pretty easy. I let it do all the work with regarding to parsing, etc. and I just follow up by parsing in the highlight codes looking for string/character markers at which point I then examine the matching characters. If I find a $ or a { then I simply replace the highlight codes with a different highlight code and presto... I am done :-). Should save me a few roundtrips during my PHP development.

The picture on the side shows what the highlighter does (see the variables in the strings). You can control the colors using Delphi's source color options.

I will update the code central entry after I am sure it is working properly.

Labels:

Sunday, February 08, 2004

Restoring Delphi Style Exception Handling to D8.Net WinForms

CodeCentral: Restores Delphi expected exception handling
I got to some tinkering with D8.Net today after putting in the base boards in the basement. I never thought the boards would make much difference but it makes the room really look finished.

As part of my exploration of D8.Net I have been coding some refreshed library based code from an application I maintain in my spare time. In order to fully explore .NET I have been staying away from the VCL components and sticking with the WinForms provided as part of the .NET Framework. Probably one of the first shocking things any of us Delphi developers will find annoying is that the application simply goes away when an unhandled exception is let loose on the system. Perhaps only if you have experience developing without the VCL in Delphi do you realize that it is the VCL that provides this safety net. WinForms does not do this by default.

So, I figured out how to add this basic feature and that led to wanting to create is as a component that I could drop on the main form of any WinForms based app. It took a while to get through all the little bits but I finally made it there. For anyone doing components/controls they should take a peek at the KnobControl that is included in the WinForms demo directory in the Delphi 8 for .NET installation.

The results are a new Code Central entry. The link is above.

Labels:

Saturday, February 07, 2004

D8.Net Update #1 has Good and Bad

The recent Delphi 8 update brings with it good news and bad news at time same time.

Library related bugs received a bit of attention (this was what I was really hoping for since I found it too much trouble to work with, now, it is workable). They have fixed the most aggravating problem with the default namespaces which means I can actually start to use it to create some library style code so that is a real move forward.

XML Comment related bugs received some attention. They fixed the "array of type" bug but did not address either XML comments in the .dpr or XML comments code completion feature. Hopefully we will see the .dpr comments fixed up in the next update. I don't have much hope for code completion but a document and stylesheets would have been nice for encouraging us to use this great new feature in the compiler.

The bad news is the IDE is much less stable (yes, less stable then before). This to be expected as they did warn that something may be up in that regard. I find it will work well for an undetermined amount of time but as soon as it starts to go to pot it seems to really like staying that way (even after restarts of the IDE). I can only guess that I am doing things in some unexpected manner and causing this grief to myself.

Overall I have to say I am very pleased with the speed in which the update was released and that my most annoying problems were addressed. Borland deserves a Kudos but they shouldn't sit back and rest. Another update to D8 and the much needed service pack for D7 are still needed. Here is hoping that D8.Net becomes production ready with the next patch.


Labels:

Friday, February 06, 2004

Delphi 8 for .NET Update is Now Available

Delphi 8 for .NET update now available
Well, that was fast and is a really good sign that Borland is going to be responsive in addressing the somewhat troublesome bugs in the initial release of D8.Net.

I know at least one of two of the bugs I logged have been addressed. I really hope something was done with the library/package issues but we will have to wait and see (Borland seemed pretty resistent that it was as designed). While I respect their arguments and decisions it doesn't mean I completely agree with the choices.

I am going to take it as a chance to reinstall the IDE since I do not prefer it in the default \Program Files\ location.

They have even included some source updates to the VCL libraries. Have quick look here.

Labels:

Tuesday, February 03, 2004

D8.Net, Carpet, and Quality Central :^)

In between laying down carpet, family, and work I have been trying to wedge some time against Delphi8.NET. I know I liked what I saw back in the D7 preview and figured I would be very happy with the final release... well, I do like it but it isn't quite where I had hoped. I figure it is at least two service packs away before being of any real use and I can start moving framework code and deciding how much existing code is going to suffer.

For now, I have been logging a few issues in QualityCentral and even found some time today to whip up a syntax highlighter sample which let me use D7, D7.1, and D8.Net all at the same time. Reminds me, still waiting on the service pack for D7 so I can feel comfortable enough to deploy with.

Labels: