Problems with Word after installing PD 11

In case anybody else has run into this, this is from a newsgroup posting from "Seth S." about how to overcome issues with Word after PD11 is installed. The problem is that Word loads the PowerDesigner plug-in by default (everytime you use Word), not just when PowerDesigner needs it. For me it's been a real issue because I use Word as the editor for Outlook, so it keeps getting loaded when I'm in Outlook as well.

One minor correction. That key shows up for me under HKEY_CURRENT_USER, not HKEY_LOCAL_MACHINE as the newsgroup post indicated.

===================================================================

The workaround is to change the LoadBehavior of the DLL in Word

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftOfficeWordAddinsWordToRqm11.Connect]
"LoadBehavior"=dword:00000002

LoadBehavior should be set to '3' and you must set it to '2'. After that Ms Word will not load the DLL anymore.

NOTE: The add-in remains listed in the Global Template and Add-in box and the contextual menu named 'requirements' is still on the menu. These things will be address in the cr 376227.

===================================================================

Must have improvements for the next version of PowerBuilder

A while back I took the new features I had suggested in my PBDJ editorial from last year, all the input from last TechWave's enhancement section discussion and all of the suggestions from a long thread a while back in the future_directions forum and I entered them into the ISUG enhancement request system.

Dynamically creating an Access database

Even need to export data in an Access database format? It may be a little easier than you think, or even the way you're currently doing it.

Two things to consider:

1. You can dynamically create a Access database file without having Access on the system.
2. You can connect to that database and write data to it without ever creating ODBC entries for it.

The first item is possible because the Microsoft Data Access Components, which are installed as part of the operating system on most recent Microsoft operating systems, allow you to perform a number of database operations through OLE Automation. The actually implemention looks something like this:

oleobject l_adocatalog
string ls_database = "c:asaexport.mdb"

l_adocatalog = CREATE oleobject
l_adocatalog.ConnectToNewObject ( "ADOX.Catalog" )
l_adocatalog.Create ( "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + ls_database )
l_adocatalog.DisconnectObject()
Destroy l_adocatalog

Of course, you would add some appropriate error checking and wrap most of the calls in a try/catch block to allow gracefully recovery from any OLE Automation errors.

The second item is accomplished through something called a "DNSless Connection". That is, rather than create an ODBC entry and point to that in the ODBC ConnectString, we simply give the ODBC drivers everything they need to get connected directly in the ConnectString. In the case of Access, all we need to do it tell it the Driver we want to use and where the file is located in the DBQ paramater, as well as the uid and pwd we would use for any typical ODBC ConnectString:

SQLCA.DBMS = 'ODB'
SQLCA.DBParm = "ConnectString='Driver={Microsoft Access Driver (*.mdb)};Dbq=" + ls_database + ";Uid=admin;Pwd='"

I've put this all together in a little sample app on CodeXchange that creates an Access data file dynamically and the pipelines data from the ASA sample database to that new Access data file.

Cleaning up the Recent Workspaces list

You know that option in PowerBuilder under Tools -> Options -> Workspaces, the command button marked "Clean Up"? It scans the registry and automatically removes references to workspaces and targets that are no longer available.

What drives me nuts is that is that the one thing that option doesn't to is clean up the File -> Recent Workspaces list. That's something I use quite frequenty, and I wish the Clean Up option would address it too.

Ajax versus Smart Clients…

Back in December of 2004, I commented in my editorial in the PowerBuilder Developer's Journal (PBDJ) about the advent of Smart Clients and how they would give us the benefits of standard client/server applications and internet applications without the downsides of either.

A couple of months later, in February of 2005, we published an article by Rahul Jain about the use of XMLHTTPRequest to develop more rich client internet applications.

Well, it appears that the XMLHTTPRequest approach is gaining some ground. It and other standard technologies like CSS and DOM, are being used in combination in a methodology called Ajax that is delivering some of the same promises that Smart Clients are supposed to bring. If you've seen Google's mail service (Gmail) or Google Maps, you've seen just what it can do.

Of course, the new beta version of Google Groups is also based on that technology. But I don't think that should reflect poorly on Ajax. It just means that even the best technology can be applied poorly. (As you might infer, I'm not particularly impressed wth the latest version of Google Groups.)

Wither VB?

In case you haven't been following, there is an online petition to Microsoft to keep classic Visual Basic alive. So far, they have over 5,000 signatures (including 241 Microsoft MVPs). I have a mixed reaction to this. On one hand, I believe it's a sign that RAD client/server development is alive and well. On the other hand, I'd like to see those frustrated VB developers become PB developers instead.

How do you deploy an ASP.NET application to a non default web site?

Well, it's a bit tricky, at least until VS 2005 arrives. Until then, take a look at Microsoft Tech Note 821335. It comes with a new version of DCPA.DLL, and a JavaScript file called EnableHostHeaders.js.

What to do with that though? Well, to make it simplier for me, I created a quick and dirty VS Add in. It's pretty simple. Just use the Add In Wizard. Then add a form to the project and code a button on it to allow you to select the MSI file:

OpenFileDialog openFileDialog1 = new OpenFileDialog();
openFileDialog1.Filter = "MSI files (*.msi)|*.msi|All files (*.*)|*.*" ;
openFileDialog1.FilterIndex = 1 ;
openFileDialog1.RestoreDirectory = true ;
if(openFileDialog1.ShowDialog() == DialogResult.OK)
{
msifile = openFileDialog1.FileName ;
textBox1.Text = msifile ;
bOK.Enabled = true ;
}

Then add another button that uses Process.Start to run the EnableHostHeaders file on the MSI file:

System.Diagnostics.Process.Start(
""c:program filesteamsybaseenablehostheadersEnableHostHeaders.js"", """ + msifile + """) ;
this.Close() ;

Finally, go back to the add in class and in the Exec function simply display the form:

EnableHostHeadersForm myForm = new EnableHostHeadersForm() ;
myForm.Show();

The add in wizard automatically creates a setup project as well. Compile the entire solution, then exit VS.Net and run the setup program outside of VS.Net. If you run the setup from within VS.Net, the changes to the Tools menu aren't saved.



From now on, after compiling your setup project for an ASP.Net project you simply run the add in on the resulting MSI file. When the setup is run now, it will display a DDLB that allows you to select the web site on the server to install to.