Key new features in RAD Studio 2010 include:

• NEW! Cutting-edge support for touch- and gesture-enabling your apps on any Windows OS, including Windows 7
• NEW! IDE Insight for instant access to any feature, setting, or component
• ENHANCED! Support for the latest databases with DataSnap™ and dbExpress™
• NEW! Support for Firebird database!
• NEW! Over 120 developer-focused IDE enhancements
• and more

Your data, where you want, how you want it - watch the videos, read the paper!

Let Bob Swart ("Dr Bob") take you from the start with building DataSnap servers and clients on Windows, right through how to use filters, callbacks and build Web targets.  Click http://www.embarcadero-info.com/in_action/radstudio/db.html to download his white paper and watch his new videos.

Please register to download the white paper at http://www.embarcadero-info.com/in_action/radstudio/db.html

White Paper: Delphi 2010 DataSnap: Your data – where you want, how you want it.

Table of contents

1. DataSnap History
2. DataSnap Windows Targets
3. DataSnap and Databases
4. DataSnap Filters
5. DataSnap Web Targets
6. HTTP(S) and Authentication
7. REST and JSON
8. DataSnap and .NET
9. Summary

Ways to stay connected and up to date with Embarcadero

• Follow Us! Embarcadero on Twitter - http://twitter.com/EmbarcaderoTech
• Watch Us! Videos on YouTube - http://www.youtube.com/embarcaderotechnet
• Network with Us! Embarcadero on LinkedIn - http://www.linkedin.com/companies/embarcadero-technologies
• Take Part! Embarcadero Events - http://www.embarcadero.com/news/events.php
• The Blogosphere! Embarcadero employee blogs - http://blogs.embarcadero.com/
• Talk Shop! Embarcadero Discussion Forums - https://forums.embarcadero.com/index.jspa

Share This | Email this page to a friend

Share This | Email this page to a friend

http://blogs.embarcadero.com/abauer/2009/08/25/38894

http://blogs.embarcadero.com/abauer/2009/08/29/38896

http://blog.delphi-jedi.net/2009/08/29/version-checking-for-delphi/

In Christian’s post and in Allen’s second post, there is discussion of the exception that is raised when a delay-loaded method can not be found at runtime.  It is this exception that is prompting D2010 users to submit QC reports.  In fact, every single one of these reports I’ve seen so far are coming from developers who are using the JVCL at design time in the IDE — in particular it appears that these developers are using a TJvCustomSpeedButton descendant.  Based on the exception, it would appear that each report was generated on a pre-Vista OS.

The error message associated with this exception is either "External Exception $C0FB007E" or "External Exception $C0FB007F."  Here is the top of the stack trace for one of these reports (this is what you’ll see if you click the "Details" button on the error message in the IDE):


[7C812A6B]{kernel32.dll} RaiseException + $52
[50011BDB]{rtl140.bpl  } System.@_delayLoadHelper (Line 302, "C:\Builds\TP\rtl\sys\delayhlp.c" + 158) + $D
[500B0681]{rtl140.bpl  } UxTheme.uxtheme.dll (Line 5112, "UxTheme.pas" + 0) + $5
[500B0712]{rtl140.bpl  } UxTheme.DrawThemeTextEx (Line 5138, "UxTheme.pas" + 1) + $20
[490EE508]{JvCoreD14R.bpl} JvThemes.DrawGlassableText + $C4
[490EE54C]{JvCoreD14R.bpl} JvThemes.DrawGlassableText + $108
[49ACF1B4]{JvStdCtrlsD14R.bpl} JvSpeedButton.TJvxButtonGlyph.DrawButtonText + $C4
[49ACF2A6]{JvStdCtrlsD14R.bpl} JvSpeedButton.TJvxButtonGlyph.DrawEx + $E2
[49ACDA81]{JvStdCtrlsD14R.bpl} JvSpeedButton.TJvImageSpeedButton.PaintImage + $C5
[49AE416C]{JvStdCtrlsD14R.bpl} JvToolEdit.TJvEditButton.PaintImage + $78
[49ACCC96]{JvStdCtrlsD14R.bpl} JvSpeedButton.TJvCustomSpeedButton.Paint + $336
[49AE4078]{JvStdCtrlsD14R.bpl} JvToolEdit.TJvEditButton.Paint + $98
[501CE436]{vcl140.bpl  } Graphics.TCanvas.SetPenPos (Line 4050, "Graphics.pas" + 1) + $9
[5029F685]{vcl140.bpl  } Controls.TGraphicControl.WMPaint (Line 13141, "Controls.pas" + 7) + $5
[49ACD58E]{JvStdCtrlsD14R.bpl} JvSpeedButton.TJvCustomSpeedButton.WMPaint + $B6
[50295DFC]{vcl140.bpl  } Controls.TControl.WndProc (Line 7062, "Controls.pas" + 91) + $6


The exception is raised because in Delphi 2010, the DrawThemeTextEx declaration in UxTheme.pas was changed from using the LoadLibrary/GetProcAddress mechanism mentioned by Allen to use the new delay-loaded mechanism. 

Below if the pre-D2010 version of the implementation of DrawThemeTextEx:
 


function DrawThemeTextEx(hTheme: HTHEME; hdc: HDC; iPartId: Integer;
  iStateId: Integer; pszText: LPCWSTR; cchText: Integer; dwTextFlags: DWORD;
  pRect: PRect; var pOptions: TDTTOpts): HResult;
begin
  if Assigned(_DrawThemeTextEx) then
    Result := _DrawThemeTextEx(hTheme, hdc, iPartId, iStateId, pszText, cchText,
      dwTextFlags, pRect, pOptions)
  else
  begin
    Result := E_NOTIMPL;
    if ThemeLibrary > 0 then
    begin
      _DrawThemeTextEx := GetProcAddress(ThemeLibrary, 'DrawThemeTextEx'); // Do not localize
      if Assigned(_DrawThemeTextEx) then
        Result := _DrawThemeTextEx(hTheme, hdc, iPartId, iStateId, pszText,
          cchText, dwTextFlags, pRect, pOptions);
    end;
  end;
end;


And here is the D2010 version:


function DrawThemeTextEx(hTheme: HTHEME; hdc: HDC; iPartId: Integer;
iStateId: Integer; pszText: LPCWSTR; cchText: Integer; dwTextFlags: DWORD;
pRect: PRect; var pOptions: TDTTOpts): HResult; stdcall; external themelib name 'DrawThemeTextEx' delayed;


Because of the change, existing code that calls this API on a pre-Vista system would now generate the aforementioned delay-load exception.  With the old mechanism, calling this method would have resulted in a "E_NOTIMPL" return value.   The JVCL code that calls this API, had error-handling code in place to properly handle the E_NOTIMPL return value, but this did not help with the new exception-raising mechanism.   I just checked, and it looks like the JVCL team has addressed this issue.  The sources contained in the current JVCL tip revision properly handle the situation by doing a Windows version check before calling the API (see revision 12491 of JVThemes.pas, committed on September 4th, 2009).  That said, if you are using the JVCL and have not yet updated to the most recent sources, you may still run into this exception in D2010 when running on Windows XP (or any pre-Vista version of Windows).  To avoid this, I would suggest updating your JVCL sources.  If that’s not practical, I would at least apply the changes made in the aforementioned revision.
 

On a related note, it would probably be a good idea for the IDE to give a better error message in this particular case.  I think that if the IDE used a solution similar to one presented by Allen in his second post, that would definitely make things much more user-friendly should an error like this occur again in the future.   Telling the user that a particular entry point is missing from a particular module is much nicer than giving an external exception with an obscure error code.   I’ll be investigating such a solution for a future release.

 UPDATE: I just noticed that Andreas Hausladen blogged on this exact issue a few months ago:  http://andy.jgknet.de/blog/?p=660

Share This | Email this page to a friend

Share This | Email this page to a friend

Technology is moving fast. Learn the secrets to getting the most out of RAD Studio 2010 and new Windows technologies by attending the RAD Studio 2010 Tour in a city near you. These free two-hour technical seminars, led by noted experts David Intersimone, Anders Ohlsson, Nick Hodges, or Mike Rozlog, will give you a firsthand look at new capabilities that will make you more productive and successful with Delphi®, C++Builder®, Delphi Prism™ and Embarcadero® RAD Studio 2010.

You’ll learn how to:

• Speed your development using new IDE and debugging enhancements
• Take advantage of new Delphi language features including RTTI
• Build apps that leverage new Windows® 7 technologies
• Touch, multi-touch, and gesture enable your applications with ease
• Migrate your earlier Delphi projects to Delphi 2010
• Rapidly create multi-tier, desktop, and Web applications
• Improve data and code comprehension and quality

Register today! All event attendees will receive:

• Special discounts on Delphi, C++Builder, Delphi Prism and RAD Studio
• Entry in a drawing for a free copy of RAD Studio 2010 and other prizes
• Discount on Delphi training from The DSW Group

To register, click the city of your choice:

San Diego, CA, November 10 - 12:30pm-2:30pm
Silicon Valley, CA, November 11 - 11:00am-1:00pm
Phoenix, AZ, November 12 - 12:00pm-2:00pm
Philadelphia, PA, November 17 - 6:00pm-8:00pm
Raleigh, NC, November 18 - 6:00pm-8:00pm
Minneapolis, MN, November 19 - 6:00pm-8:00pm
Sacramento, CA, December 2 - 6:00pm-8:00pm
Los Angeles, CA, December 3 - 7:00pm-9:00pm
Denver, CO, December 8 - 5:00pm-7:00pm

More cities and dates are being added. Stay tuned to this page for updates.

The U.S. tour home page can be found at http://www.embarcadero.com/rad-tour-2010-free-seminar

Share This | Email this page to a friend

Para tener mas información y adquirir el libro, clic aqui

Share This | Email this page to a friend

So please sign up – I’d love to see you all again or meet you for the first time, as the case may be.  And remember, it’s all free!

Share This | Email this page to a friend

Share This | Email this page to a friend

The default allocator you get when you call malloc has a bunch of debugging support built in.  Some of it is enabled all the time.  For example, try this:

#include <stdlib.h>
int main(void) {
  void *p = malloc(10);
  free(p); free(p);  // <- hey look: bad code
  return 0;
}

If you compile and run this, you’ll get this:

bash-3.2$ ./a.out
a.out(11352) malloc: *** error for object 0x100120: double free
*** set a breakpoint in malloc_error_break to debug

This support pointed out a few goofs for us early in the RTL development stages.  I’ll not go into all the details of the OS X memory manager; there is a lot of good documentation on it available, so I’ll just provide some pointers:

• Malloc Debugging Features
• OS X Debugging Magic

The links above include some details about the various switches you can apply to the memory manager, plus some additional custom malloc debugging libraries, plus some cool tools that are included in the shipping OS for analyzing allocations.  Worth a read.

I suppose the first question I asked myself when I saw this was "Doesn’t that have an adverse performance effect on applications?".  I think there are several answers to this.  One is "Apparently not".  Another is "To a degree".  The first one comes from simple observation that the platform generally rocks.  The second is due to reading various arguments and analyses on the web, some of which say the OS X allocator is slower than Linux, but has improved, some of which say these analyses are not very real world, and if you do real world tests, the OS X allocator rocks pretty well.  Forgive me the weasel words - I admit to not doing in depth research on this.  I haven’t had time to find or come up with a definitive answer for myself here.  I may come back to the topic at a later date, though if the allocator doesn’t really show itself to be a problem when we profile things, I’m not going to worry about it.  Mostly my point in blogging today was to make newcomers to the Mac platform aware of the fact that there is quite a bit of debugging and profiling support built right into the platform that is worth looking at and learning about.

Share This | Email this page to a friend

The feature I’m talking about is the addition of the debugger option called "Ignore non-user breakpoints".  In the 2010 release, this option can be found on the "Embarcadero Debuggers" page on the Tools | Options dialog (or you can use IDE Insight to find it).  In previous releases the page would have been called either "CodeGear Debuggers" or "Borland Debuggers", depending on the company name at the time of the release.

This function of this option should be self-explanatory — the only thing that might not be clear is what exactly constitutes a "non-user breakpoint".  A non-user breakpoint is any breakpoint that you have not explicitly set in the IDE.  There are a couple of different things that cause a non-user breakpoint to be triggered.  Some common causes:

1. A hardcoded breakpoint using inline assembly.  The assembly instruction for a breakpoint is "int 3".  If you have any inline assembly that includes this instruction, a breakpoint will be triggered if you are running under the debugger when that instruction is executed.
2. A call to the WINAPI procedure "DebugBreak".  If you have code that calls this procedure, a breakpoint will be triggered if you are running under the debugger when that procedure is called.
3. Pressing F12 in an application that is running under the debugger.  This hotkey is controlled by the OS (on by default for XP, can be disabled; off by default in newer Windows versions, can be enabled).  It basically causes an app that is running under the debugger to break back into the debugger via a breakpoint.
4. Sometimes passing bad parameters or data to some WINAPI functions causes those functions to trigger breakpoints if you are running under the debugger.

There may be other situations that cause a non-user breakpoint to get hit.  You’ll know you’ve hit one by looking in the CPU view after your application unexpectedly breaks back into the debugger.  If you see an "int 3" instruction in the CPU view at the address immediately preceding the instruction at the address indicated by the current EIP, you can be pretty sure you’ve hit a non-user breakpoint.  All of the common causes mentioned above boil down to an "int 3" instruction getting executed by the app being debugged.

Using the "Ignore non-user breakpoint" debugger option, you can tell the debugger that you don’t want your process to stop when it encounters one of these.  When that happens, the debugger will respond to the breakpoint triggering by just setting the process running again — there will be no indication that a non-user breakpoint is hit.

This can be especially useful for case #3 above — if your app uses F12 as a hotkey, and you need to debug its handling of the F12 key on XP, but don’t want to disable it globally on your system.

Share This | Email this page to a friend

Share This | Email this page to a friend

We haven’t had the time and resources to produce a product that meets our quality and performance standards.  C++ is a very complex language as you know, and we won’t release a feature until we know we have something that will handle the complexities of the language without sacrificing usability.

To: Chee Wee Chua Re: Sanjay

He left the company about 2 years ago.

Share This | Email this page to a friend

I first joined Borland in 1999 to work on compiler optimizations for a new back-end we were developing in-house to host our tools on other platforms besides Windows.   Many years, a few company names, and many projects later, I’m still here doing my part to ensure our tools, now owned by Embarcadero, are truely RAD.

Share This | Email this page to a friend

Share This | Email this page to a friend

Share This | Email this page to a friend

Before looking at that, let’s quickly review how naming threads for the debugger works.  The concept of naming threads in Delphi and C++Builder is not new (if I remember correctly the debugger support was added in the 6.0 versions), and it was modeled after other tools that supported that same mechanism.  Basically the debugger listens for a specific exception type (one with an exception code of $406D1388) within the application being debugged.  When this exception type is raised by the application, the debugger recognizes the exception type and cracks open the structure passed to the RaiseException call to extract the thread name.  It will then apply this name to the appropriate thread (which is also determined by looking at the structure that contains the name).  The most common case is to name the thread that raises the exception, but this mechanism also supports naming any thread running within the process from any thread running within the process.  For reference, this MSDN article shows how to do this from an application.

This mechanism is also supported by other Windows debugging tools (including Visual Studio and AQTime).

In previous Delphi and C++Builder versions, you would have to provide all the code yourself to name a thread.  If you created a thread using the "Thread Object" item that appeared under either the "Delphi Files" or "C++Builder Files" section of the File | New | Other dialog box, you were given the option to name the thread you were about to create.  If, however, after the fact, you wanted to go back and name your thread, or if you had a thread that you manually created,  you were on your own to copy/paste the appropriate code into your thread object.

Now, however, the Delphi RTL has built-in support for doing this.  You can now easily name any thread using a single function call.  The TThread class now has a new method:

    class procedure NameThreadForDebugging(AThreadName: AnsiString; AThreadID: LongWord = $FFFFFFFF); static;

The simple case is to call it passing in just a string representing the name for the thread.  In that case, the debugger will name whichever thread makes the call.  If you want to name a different thread, you can do that by also passing in the OS thread ID that corresponds to the thread you want to name.  Because this is a class method and because the second parameter can be the thread id of any thread in your application, you do not even need to be within a TThread object to call it, and in fact, you can call it to name a thread even if that thread is not a TThread descendant.  Two other things to note:  first, this new method does nothing if the application is not running under a debugger (IsDebuggerPresent returns false); and second, the code that raises the exception for the debugger is wrapped with an emtpy try/except block to ensure the exception doesn’t bubble out of the NameThreadForDebugging procedure.

Even though thread naming has been around for a while, it wasn’t until this small addition was made to the RTL, that we (the IDE team) made a concerted effort to name the threads created by the IDE.  As soon as it became dead-simple to name a thread, it was a simple matter of hunting down the threads created by the IDE and adding a single call to each thread.  For TThread descendants, we just added a single call as the first line of each thread’s overridden "Execute" method.

This alone has made debugging the multi-threaded parts of the IDE much simpler.  When debugging a crash or a thread-contention issue, you used to have to double-click the various threads in the Thread Status view and then look at the Call Stack view in order to find a particular thread.  Now, with most of the critical IDE threads named, it is a simple matter of locating the thread, by name, in the Thread Status view.  And naming all our threads, has made it possible for use to effectively use Thread-Specific Breakpoints, and the new Thread Freeze/Thaw mechanism that was also introduced in Delphi 2010 and C++Builder 2010.

Share This | Email this page to a friend