Your account information is the same
When we CodeGear became part of Embarcadero Technologies, we also launched the Embarcadero Developer Network (EDN), which is an improved version of what used to be the CodeGear Developer Network (dn.codegear.com) and Borland Developer Network (bdn.borland.com). Any accounts you may have used on BDN, or for registering your CodeGear products, can be used to login here. You should have all the same access here as you did on BDN.
You can learn more about the membership services we provide in New membership services.
Login form improvements
Our login form was a bit confusing because it has two different values you can use to identify yourself: login name, and email address. The problems people had logging in were usually caused by using a "login name" that didn't match the email address also entered on the login form.
Unfortunately, the interface didn't make it clear that login name took precedence over email addresss. If the login name value is filled in, it is always used for the login attempt, regardless of whether or not the email address has been entered.
We have updated the login form to make this precedence clearer. When you provide a login name value now, the email address entry becomes disabled. We have also made the text of the form, and the tooltips, clearer.
If you have an existing "BDN" or Borland account, you can use the same login information for the CodeGear Developer Network because we still share the same user account information.
A technical digression
Dynamically disabling the email address text box was not as trivial as it would first appear. Every user action that should enable or disable the email address edit box needs to be detected, but this took a bit of testing with different browsers to make it work consistently and intuitively. (Maybe next century browser incompatibility issues will finally be resolved.)
Gillmer Derge and I worked on the issue a bit. There's a very handy reference for form events we used while trying to solve the problem: http://www.blooberry.com/indexdot/html/tagpages/attributes/events.htm.
Whenever the login name has any value in it (i.e., it is not blank), the email address edit box needs to be disabled. Whenever login name is blank, the email address edit box must be enabled.
This is the relevant part of the ASP.NET aspx page we finally were happy with:
(document.forms['_ctl0'].LoginName.value != '');
<ASP:TextBox id="LoginName" runat="server" width="284px"
The tedious part, however, was learning which events to wire up for CheckLoginName(). We finally determined that the following events were needed to make sure both FireFox and Internet Explorer would provide a consistent user experience. Hopefully this works in all other modern browsers as well.
This event fires whenever the value in a control is changed by either keyboard or mouse (support for both is the important part) and the element's contents have changed. This needs to be tracked to detect if the mouse was used to clear the login name value.
Not used. This event will fire when login name is cleared via the keyboard, so email address can be enabled. However, in IE, you have to put two (2) characters into login name before email address will again be disabled. We ended up not needing this event at all, because OnKeyUp works in both browsers.
This event was used to address the "two character" bug exhibited in IE with OnKeyPress. By using this event, email address is correctly disabled when the first character is typed into login name.
Here are some samples of the form controls responding to different values:
1 Login name not empty and email disabled
2 Login name empty and email enabled
I hope you find the new login form dialog less confusing, and that the technical information is valuable for anyone needing to provide the same kind of functionality on their browser forms.