In my last blog post I mentioned an issue with IE7 and BDS where the ASP.NET designer fails to load with an "Access Denied" error and I also updated that post with the workaround though I feel it's important enough to have it's own post. It turns out that this is "as designed" by Microsoft and to get around the issue people will need to use the following workaround in order to get the IDE working again. Here is what Microsoft had to say about the problem:

Btw, I'd like to thank Microsoft and the IE compatibility team, they've been very helpful working to resolve issues related to IE7.

I've been playing with AJAX a lot lately and thought it would be good to post an AJAX example using Delphi for .NET. There are lots of AJAX libaries/frameworks available and the one I've chosen for this example is magicAJAX.net. Rather then reinvent the wheel I've taken this example and converted it to use Delphi.

I'm going to assume you'll be running this example from IIS. To get this example to work in Delphi for .NET you'll need to do the following:

1. Grab the magicAJAX.net download from here. All you're really going to need is the magicajax.dll assembly.
2. Download the Delphi example source code here
3. Unzip delphi_magicajax.zip into \inetpub\wwwroot (it contains a directory called DelphiMagicAjax)
4. Create a virtual directory under IIS and point it at the directory created above
5. Under \inetpub\wwwroot\DelphiMagicAjax create a directory called "bin"
6. Unzip magicajax.dll from the download in step 1 into the bin directory created above
7. Start the IDE and open DelphiMagicAjax.bdsproj
8. From the Project Manager right click References and select Add Reference and add magicajax.dll
9. Compile and run the project, you should see a page that looks like this

To add the magicAJAX.net panel to your palette:

1. Select Component | Install .NET Components...
2. Click Select an Assembly and locate magicajax.dll and click OK

For more information check out the magicAJAX.net website.

Tags: borlanddelphiajaxaspnetmagicajax

One feature I've mentioned but haven't directly discussed is Delphi's HTML/ASP.NET Tag Editor window. This is a small code editor at the bottom of the HTML/ASP.NET designer that displays the markup of the selected tag. In Delphi 2006 the Tag Editor includes the following features:

• Live markup tag editing including ASP.NET controls
• Code completion
• Markup error insight
• Tag zooming or the ability to "zoom" out to the selected tag's parent up to the tag
• Designer tag highlighting (see the yellow region on the designer below) so it's easier to see what markup is reflected in the tag editor

Here is a screenshot of the ASP.NET designer including the Tag Editor (click to zoom):

This screenshot highlights many features of the Tag Editor including error insight, code completion and designer tag highlighting. Additionally, if you've worked with ASP.NET at all you can appreciate the fact that the Tag Editor makes it easy to edit things like asp:datalist templates without having to switch back and forth between the designer and the code editor.

The Tag Editor isn't limited to editing existing markup as you can easily enter any new markup and immediately see the results in the designer.

My blog has been pretty quiet for the past few months as I, and the rest of the development staff have poured time into working on Delphi 2006. I've discussed here many of the details of what we've been doing and now you have the chance to see for yourselves. For those of you who have used Delphi 2006 I'm really interested to hear how you think we did on improving product quality? I'd also like to know what you think still needs work?

tag: borland delphi

In light of the public display of the roadmap I thought I'd mention a few of the improvements to the product in relation to the HTML/ASP.NET designer. As I've mentioned before a major focus on this release has been quality but there are plenty of new and exciting features as well. Related to the ASP.NET designer we've added:

• Markup source preservation
• Tag Editor Error Insight (screenshot)
• Improved project deployment
• Improved ASP.NET project management
• Improved Tag Editor markup editing
• Improved project load performance
• Lots of designer performance improvements

"we spent about two to three developers for about two years working on that problem" -Scott Guthrie, Product Unit Manager on the Web Platform at Microsoft

Whoa, now that's some significant development time! I did mention here that we had our work cut out for us. :) The above quote is from this video where Scott is discussing features of the (long delayed) release of VS.NET 2005 which is now slated for sometime late this year.

Like Microsoft we also feel this is a significant problem which we will be working on in our next release of Delphi. Stay tuned!

As I'm working on features for our next release I've been wondering if people are using HTML Tidy as their default formatter for HTML in the Delphi IDE? I've discussed issues regarding HTML Tidy and ASP.NET here before and at this point since HTML Tidy simply doesn't support ASP.NET I'm thinking it's time to remove the option to use HTML Tidy as the default HTML formatter from the IDE. We can still provide the option to format using Edit|HTML Tidy|Format document so we won't completely remove HTML Tidy support.

I know this issue has been pretty well discussed but someone recently asked me about it again and I put together a small example to help illustrate the problems that arise when using the MSHTML control and trying to preserve source code.

Here is what we hand the MSHTML control

we get this back (without editing anything btw):

Now, to point out the differences...

1. All tags are now uppercase
2. runat="server" on title tag is gone
3. Missing the first closing (notice the last one is preserved)
4. A single space was added between "two" and
5. The wrapped text has been unwrapped
6. The order of the table tag attributes has been reversed
7. The quotes around the table tag attribues have been removed
8. The case of the table tag attributes has been changed
9. TBODY tag has been added
10. A closing TR tag has been added (but no closing TD??)
11. All whitespace has been removed (except of course where it was added see above)

So, as you can see when it comes to source preservation using the MSHTML control we definately have our work cut out for us thus we currently reformat the markup to make it readable again. I'll have more on this later.

When update 2 of Delphi 2005 comes out one of the additional features of HTML Error Insight (the squiggly error underlining in the code editor) will include detection of duplicate tag ID's. This feature will allow the developer detect and correct duplicate tag ID's without having to run the application and wait for the ASP.NET runtime to flag the error for you. There have been numerous other improvements to HTML Error Insight for Update 2 but I think this is probably the most useful one and thought it was worth mentioning.

Now that Danny has explained, with this post the real story behind Borland's Delphi.NET Compact Framework (CF) support I'll throw my hat into the ring regarding the ASP.NET designer support.  Basically, it's the exact same story as CF in that it doesn't exist outside of VS.NET and if you want an ASP.NET designer you'll need to write it from scratch.  Well we've done exactly that with Delphi.NET and C#Builder, in other words we implemented Danny's option number 3 (refer to the link to Danny's post above).  As Danny mentioned this is the most flexible option but, as he said, it does come at a high cost.

As ASP.NET 2.0 takes shape, in some ways, we've been in a bit of a holding pattern watching and studying the level of support that the new designer provides.  Had there been designer support in the framework that we could have leveraged perhaps we'd have been able to spend our time working on additional supporting features rather than cautiously planning and implementing just the features we feel will truly make it into the final release.  Additionally, Microsoft has all but removed .NET 1.1 designer compatibility from .NET 2.0 by not only deprecating old methods but at the same time making them  stubs so they don't even do what they used to do; two steps forward and one giant step back.  I agree with Danny when he says that he doesn't think all this occurred because malious intent on Microsoft's behalf but I think third parties like Borland could argue that it's perhaps not the best way to get other's to support your framework which we're really working hard to do.

Let's imagine for a second that the ASP.NET and CF designers had been implemented like the WinForms designer.  Had that been the case I think it would be reasonable to assume that third parties could have spent their time finding ways to make developing for the .NET Framework that much more compelling rather than reinventing an already existing wheel.

I suppose it's necessary to ponder the reasons why Microsoft decided to leave these two key designers out of the framework?  Danny already discussed the case for the CF framework so I'll take on the ASP.NET case.  This is an interesting situation because Microsoft has actually implemented two ASP.NET designers themselves: VS.NET and Web Matrix.   Why is that Web Matrix was developed within the ASP.NET team separate from VS.NET?  Did the ASP.NET team not like the implementation of the VS.NET designer?  Was it too different from the way previous versions of ASP worked (code behind vs. inline)?  Was this a way for the framework guys to “twist the arm“ of the VS.NET guys into implementing certain features wanted by producing a competing (ok, perhaps that's a stretch) free product?  Or are these arguments conspiracy related and did the ASP.NET guys just want a free tool to further their platform?  Perhaps we only have to look as far as VS.NET 2005 which includes support for inline pages and the VS Express versions which are free.  Considering that Web Matrix has staggnated with the “reloaded“ version and the last “call for feedback“ on Web Matrix was made in 2002 I sort of doubt we're going to see another update of Web Matrix any time soon.  Ok, so maybe the ASP.NET and VS.NET guys have worked out their differences (if there were any).  It will be interesting to see what happens to Web Matrix when the .NET 2.0 framework hits the streets.  Will Microsoft still prominently display Web Matrix on www.asp.net when it's woefully out of date?

There are also the questions of designer implementation.  In VS.NET, prior to 2005, the ASP.NET designer was based on the MSHTML control which had some obvious pluses but some considerable minuses as well, for example, the the well known formatting issues (which btw, Microsoft recently stated at VS Live took 3 developers 18 months to solve).  In VS.NET 2005 use of (at least the publicly available version and no I have no idea if they are using an internal version of MSHTML or perhaps the Front Page designer or even a completely new designer) of the MSHTML control is no longer part of the designer.  In light of the recent IE7 announcement I wonder if any of the MSHTML editing issues will be addressed since they may not be important now their own designer has parted ways?

There is also the argument that if the WinForms designer had never been released all this would be moot.  Right?  That's hard to say but it wouldn't be hard to believe other vendors would have joined the party if these other designers were available today.  Take SharpDevelop for example, without the WinForms designer it might have been little more than a code editor/debugger then again, maybe not, but the forms designer does make it a lot more appealling.

Where to from here?

Fortunately, since Borland has already made the “more expensive“ decision regarding the ASP.NET designer it will be less work for us to move to 2.0 than it would have been otherwise.  In fact, we've already made some good progress.  Additionally, since we own the designer we've had the ability to extend it with things like the Tag Editor and in the 2.0 timeframe we'll have the same opportunity.  Hopefully, we won't have to make the “more expensive“ decision regarding some of these other designers.

In the long run, perhaps it will boil down to whether or not Microsoft is interested in an active third party tools market with companies really extending the reach of the platform rather than reinventing the various designers required to even play in the same sandbox.  Just as Firefox has pushed Microsoft to update its admittedly lagging web browser, competition in the tools space can equally push Microsoft's own tools and thus their platform, which in the end is their real win.  Let's hope some of the people responsible for the WinForms designer decisions can influence some of these other critical areas of the .NET world within Microsoft.  Avalon anyone?

Now that it's pretty widely known that we're doing a Delphi 2005 Update 2 patch I think it's safe to mention that the bug discussed here has been fixed and will be included in the update.

In Delphi 2005 there is a bug which causes the runat="server" attribute to be removed from the ASPX file. The problem occurs as a result of the underlying MSHTML control removing the attribute, one of the many nuances about using this control. In fact, VS.NET 2003 has the very same problem and as such people had come up with numerous ways to work around the issue.

Here is a link with a few pages which mention ways to work around this problem. The basic idea is to simply avoid using the runat="server" attribute on the the title tag and use either a user control or an asp:literal control for the contents of the title tag.

I suppose the next question is that if we knew what the issue was then why didn't we fix it for Update 1? Well, we did fix it for update one but the fix involved a package change that would have broken resource string compatibility causing us to further delay the update. So, for now we'll have to live with the workarounds.

When you install Delphi 2005 with the intention of developing ASP.NET applications on IIS you are given the opportunity to allow the install to change your machine.config file in order to support ASP.NET debugging.  Well, during our internet chat session the other day someone asked “What are those settings?”

Well, for Delphi 2005 here is the answer:

Open %systemroot%\Microsoft.net\Framework\v1.1.4322\CONFIG\machine.config using Notepad.

1. Under the element <compilation...> there is a subelement <assemblies> to which you need to add the following:

   <add assembly="Borland.dbkasp, Version=9.0.0.1, Culture=neutral, PublicKeyToken=b0524c541232aae7" />
   

2. Then, search for <httpmodules> element and add:

   <add name="DbgConnect" type="Borland.DbkAsp.DbkConnModule, Borland.dbkasp, Version=9.0.0.1, Culture=neutral, PublicKeyToken=b0524c541232aae7" />>

That's it. Adding those elements will ensure that you can debug ASP.NET applications using Delphi 2005 on IIS. These settings are only required if you are debugging ASP.NET applications running on IIS they are not required for Cassini or any other web server.

Without these settings you will likely see the error message “Unable to attach to ASP.NET worker process (typically aspnet_wp.exe or w3wp.exe)” or something close to it.

We recommend that you either use these settings in machine.config OR in each ASP.NET web application's web.config file but not both. Additionally, you do not want to deploy a web.config file that includes these changes.

The title of this post is an error message that can occur if you are using Delphi 8.0 and trying to create an ASP.NET application using IIS as the target server.  I wrote this error message and for that I apologize, as it's a terrible message.  The error typically occurs when the IDE is unable to utilize ASDI (an IIS API) to create a virtual directory for the new application.

In Delphi 2005 I've tried to improve this message which now reads as follows:

"Creation of a virtual directory "yourvirtdir" on the local IIS Web server failed. The Web server may not be installed, not running or misconfigured. Without the virtual directory you will be unable to run this application however, you can manually create the virtual directory using the IIS administration tools at a later time. Would you like to create the application anyway?"

So, if you are using Delphi 8.0 and you encounter this error please substitute the above text in it's place.

This issue has come up on the public Delphi newsgroups and I replied briefly with some additional information and thought that perhaps a better explaination of the issue might be useful/interesting at least to some people.

In C#Builder, Delphi 8.0 and now Delphi 2005 the readme states that the HTML/ASP.NET designer do not support switching of modes while the designer is visible.  Now you might be wondering why?  What's the problem?  Well here is the answer (in what is likely more detail than perhaps anyone wants):

The Galileo IDE (what we call it internally) which is the host for C#Builder, Delphi 8 and now Delphi 2005 supports two modes for the code editor window, docked and undocked.  This, more or less, means either a single window IDE or a floating version (like all previous releases of Delphi).  In order to switch modes a lot of “stuff” has to happen behind the scenes to ensure that the switch works properly.

The main reason the HTML/ASP.NET designer does not support switching modes is that the MSHTML control (which we use as the design surface) has to be destroyed and recreated.  That sounds easy enough but the problem is that you could be in the middle of a document that has not yet been save which is where the complications start.  In order to handle the destroy/recreate of the browser window the content has to be streamed off and then restored after the designer is recreated.  This isn't necessarily a problem either, although you'd lose context information like selection and caret position in the process, but it has to be performed at the right time in order to work correctly.  Currently, the IDE is implemented so that designers don't have to have intimate details of what the rest of the IDE is doing.  They get notifications when various events occur and can respond accordingly however the dock/undock event is not one of the events that is currently propogated to the designers making this a more difficult problem to fix.  In the end, it's simply come down to us focusing more on delivering improvements to the designer itself since we felt that this issue probably won't effect a large number of customers.  Having said that I will say that fixing this problem is on our radar and hopefully something we can get to soon.

If you haven't already seen our DBWeb controls I highly recommend taking a look at them once Diamondback hits the streets. Our DBWeb controls are a set of data aware ASP.NET controls that allow you to not only manipulate data at runtime but also view the data on your WebForm at design time. If you haven't played much with ASP.NET you might ask "why is that a big deal?" since design-time data has long been available in the VCL form designer. Well, for starters when Microsoft shipped ASP.NET (1.0 and 1.1) their data aware controls required (and still do btw) data binding code before they will render any content which means they only render content at runtime.

For example, when you drop down an you see that it comes prepopulated with some fake data and that's all your ever going to see at design time. In a DBWeb control, once you connect it to an active data source you'll immediately see the data in the ASP.NET designer just like you see data in the VCL forms designer. Again, you might be saying to yourself "that's really no big deal I don't need to see the actual data". Well, picuture this you have a grid that once it's populated with data is going to run right off the righthand edge of the page you've spent so long making look really nice. Wouldn't you rather discover that as soon as you hook up the control rather than having to run the application for each and every control you add to the page to just to see how the control will morph when it contains data?

We first introduced our DBWeb controls in C#Builder and in Diamondback we've continued to improve them and add additional controls for things like sound and multimedia content. Additionally, you can feed the controls data from an XML file so it's easy to quickly prototype a data driven web site without even having to setup a database.

Back when I was working on BorlandC#Builder I made the decision to incorporate the W3C's HTML Tidy formatting tool directly into the IDE.  It has lots of options and does a nice job of formatting and correcting errors.  There are several ways to leverage HTML Tidy in the IDE, for example when editing an HTML file from the code editor you can select Edit | HTML Tidy | Format Document or Edit | HTML Tidy | Check Document for Errors.  Additionally, you can also select to use HTML Tidy as the default HTML formatter for both HTML and ASP.NET pages.  What isn't obvious is that we had to do a tremendous amount of work to get HTML Tidy to play well with ASP.NET controls but even with all the work we did it still won't format certain ASP.NET controls correctly. 

Since ASP.NET tags are not part of the HTML specification it is necessary to provide Tidy with a list of new tags and how they should be formatted.  Tidy has several options allowing you to control how new tags are formatted using either block, inline, empty or pre.  In C#Builder and Delphi 8.0 we automatically discover any ASP.NET tags within an .aspx page and prepopulate these settings prior to formatting allowing Tidy to format the ASP.NET tags as it would any standard tag.  There are lots of ASP.NET tags and subtags and without this feature it would be incredibly tedious to try and use HTML Tidy to format ASP.NET pages.

One problem however is that some ASP.NET tags support templates, meaning that they can contain fragments of HTML which should not be modified during the formatting process.  Unfortunately, HTML Tidy has no way to deal with ASP.NET templates and will in fact reformat the tag and completely change it's meaning.  As you can imagine this is not a good situation and unfortunately there is no workaround.

HTML Tidy does provide support for various web scripting languages like PHP and ASP and I think as the popularity of ASP.NET grows that it would be great if HTML Tidy could provide support for it too.  If the support can't be built into HTML Tidy then there needs to be some alternative whether it's a callback or some other mechanism that would allow the developer to improve Tidy's ability to deal with tags that it's not familiar with.

Over the past year and a half I've have seen a handful of requests for Tidy to support ASP.NET but unless more people speak up and voice their opinion I'm afraid it will be a long time before that will happen.

Here's where you come in, if you'd like to see this situation improve please visit the HTML Tidy website, get involved either by asking the great set of developers who keep this code base alive to support ASP.NET or by grabbing the code, diving in and adding it yourself (of course read all of the guidelines before doing that).

While you're there also make a case for separating how HTML Tidy options are passed so that things like the Borland IDE's aren't tied to the Tidy config file format.  I'd really like to see the command like option handling separated so that IDE's can load options from whereever they store them whether it's the Windows registry or an INI file or whatever.

A few other notes, I'd like to thank the people who work on HTML Tidy for all of their effort.  They do a great job and have been very helpful and responsive whenever I've had questions.  Additionally, I'd also like to point out that we used Jeffrey Pohlmeyer's TidyPas Pascal interface.  Btw, both of these are mentioned in our IDE's Help | About box.

To start off I'd like to address the issue of why we need a formatter at all. Our ASP.NET/HTML designer leverages the MSHTML control as its design surface and as a result we have to deal with the fact that this control discards any/all formatting including whitespace preservation when working with HTML. If you'd actually like to see the effect of using MSHTML without a formatter (trust me you won't be happy) simply rename htmlfmt80.bpl in your Delphi 8 bin directory, start the IDE and answer Yes to the "continue to load this package" error and start editing an HTML file. This package contains our HTML formatter and without it you simply get back the raw HTML from the MSHTML control.

One decision we made in Delphi 8 was to format only the content of the file starting after the first tag. There were several reasons we did this but the main reason was that we wanted to format as little of the file as possible and since many pages have sections that contain stylesheet and scripting information we thought this would be a good idea. As it turns out this wasn't a very good idea and in some cases can result in HTML being either mangled or duplicated neither of which is good. It is possible in Delphi 8 to undo the changes made in the designer using Edit|Undo but that's not always acceptible either.

In Diamondback we've completely fixed this problem and not only improved our formatter but also have relaxed the rules for creating non-HTML documents using the ASP.NET designer. For example, if you want to create an ASPX page that returns only XML (like an RSS feed) simply start a new ASP.NET page and delete all of the contents except the @ page directive at the top of the file then start adding your markup and the designer won't mess it by trying to turn it into an HTML page. As a side note, we've continued to monitor the progress of the W3C's HTML Tidy open source project and have worked to keep our libtidy.dll up-to-date.

Diamondback, like Delphi 8, supports code completion on ASP.NET server controls from within the code editor as well as the tag editor.  This makes working with ASP.NET tags much easier and helps prevent mistyping tag and attibute names helping keep your development time productive.  In Diamondback we've changed the loading of schema files that describe ASP.NET server controls such that third party companies that produce ASP.NET controls and make their controls work like first class citizens in the Diamondback IDE with full support for code completion and HTML Error Insight (a topic for another day).

To take advantage of this feature all you have to do is create a .xsd file that looks like the ones provided with Diamondback and place it in the “..\schemas\asp schemas” under your Diamondback root directory.  When the IDE starts it loads all of the schemas from that directory for use with various IDE features like code completion.  If you are a vendor who already has a schema file for VS.NET then typically just dropping that file into the above directory will add first class support to the Diamondback IDE.

In continuing my posts on new ASP.NET features in Diamondback today I'll mention ASP.NET template editing. Several ASP.NET controls support what are called templates which are small fragments of Text/HTML that the control uses are runtime. Controls that support templates like or template columns within a require a special template editing mode necessary to edit the template in the WebForm designer. Basically, template editing is a special sub-edit mode of the control used within the ASP.NET WebForm designer, something that wasn't supported in Delphi 8.0 but fully supported in Diamondback. In Delphi 8, you can use the code editor to manually edit control templates and in Diamondback you'll be able to use the template editor right within the WebForm designer which supports drag/drop and direct editing of the template. Additionally, with the tag editor, the small edit window at the bottom of the WebForm designer, you can immediately see the code within your templates which is a feature unique to Diamondback. Template editing is one of the many improvements to ASP.NET development we'll be delivering in Diamondback.

In Delphi 8 we didn't really provide any support for developing CSS/stylesheets which any web developer knows are an important part of web development.  Well, fortunately Diamondback (the next release of Delphi) supports CSS syntax highlighting as well as CSS code completion making it easier to build stylesheets where you don't have to constantly refer to reference material in order to create a new style.  I highly recommend familiarizing yourself with CSS so that you can leverage the many advantages it provides.  Here is a great site that has lots of information to help you learn CSS.

Another issue in D8 was that the designer wouldn't always resolve relative file locations for things like images and stylesheets correctly which has been fixed in Diamondback.

Here are a few pointers regarding how relative paths are resolved in the Diamondback IDE:

• If the file is part of an ASP.NET project then it's references will be resolved relative to http://localhost allowing for use of virtual roots to refer to global image and stylesheet locations.
• If the file is not part of a project (like a standalone .htm file) then any relative URLs are resolved relative to the directory path of the .htm file.

Basically if the file is part of an ASP.NET project then any relative URL references in the file are resolved through http://localhost rather than the file system.

When it comes to web applications deployment is an important part of the application development cycle.  Typically, developers will work on a local version of a web application and once they have the application working/fixed they'll deploy it to a production server.  Well, in Diamondback (the next release of Delphi) that part of the application development process is going to be a whole lot easier.  We've developed a web deployment feature that gives the developer a means of quickly and easily deploying ASP.NET applications.  There are two built-in transports, FTP and file copy, which allow the developer to easily move an application from their development machine to either a production machine or even another location on their development machine. 

Additionally, as application development proceeds the Deployment Manager displays a list of the files that need to be redeployed as a result of changes made by the developer.  Since deployment targets are simply added to an ASP.NET project it's also easy to deploy a single application to multiple targets.  The Deployment Manager comes preconfigured to for ASP.NET applications making it easy to create a new deployment that will typically include all of the necessary files for your project without any additional intervention although the Deployment Manager is highly flexible and allows for addtional files to be added by the developer as necessary.  The Deployment Manager is a great example of a product area where customers gave us feedback indicating that this was a crucial area of ASP.NET application development where they needed a solution which we took seriously and Diamondback will deliver a solution.

Jim Tierney of Delphi R&D has posted an informal patch for the ASP.NET designer to CodeCentral.  The patch addresses the following issues:

• Loss of HTML when saving a modified .aspx file while the designer is not shown, typically when the .aspx file is opened with the project desktop.
• Editor status bar not updated when editing and saving.
• Editor tabs not updated when editing and saving.
• Object inspector not displaying correct elements when switching between .aspx, designer, and .pas
• Object inspector not displaying correct elements after saving.

Even if you downloaded Jim's original patch which was uploaded to the .attachments public newsgroup you should st