Philip Stears | DriveWorks

DriveWorks and SolidWorks x64

A question cropping up more frequently is whether we support 64-bit Windows - the answer, as I am sure you can guess, is yes; but there are a few things to be aware of before going down the 64-bit route with DriveWorks.

The first thing to note is that if you are running a 32-bit version of SolidWorks on 64-bit Windows, none of this really matters - you can use DriveWorks the same way you do now. 'nuff said, catch you another time :-)

The next thing isn't really a DriveWorks thing, but if you are using the Microsoft ODBC Control Panel to administer any of the databases you work with, you are going to need to use the 32-bit version located at C:\Windows\SysWOW64\odbcad32.exe - the version located in the normal control panel area is the 64-bit version (even though it is still called odbcad32.exe - I guess you can't have everything). If you have no idea what I just said - you probably have no need to worry.

So, with all that said, lets start with what you need to know about DriveWorksXpress. The latest version of DriveWorksXpress is fully compatible with 64-bit SolidWorks, but after installing it you won't see it listed in your Tools menu.

What gives? basically, you have to run an additional program which will register DriveWorksXpress with SolidWorks x64, if you go to www.driveworksxpress.com you will see the file "ComInstaller.zip" located at the bottom of the page, just unzip that into the DriveWorksXpress directory after installing DriveWorksXpress (e.g. C:\Program Files (x86)\DriveWorks Ltd\DriveWorksXpress 2007\ComInstaller.exe) and run it - that's all there is to it.

For SP1 of DriveWorks Administrator and DriveWorks User however, there is one caveat - as you may know, DriveWorks supports working with both Microsoft Access, and the more scalable SQL Server platform. However, Microsoft do not support 64-bit programs working with Access databases - the bottom line being: DriveWorks Administrator and DriveWorks User only work with SQL Server databases when using SolidWorks x64.

There is no separate add-in registration utility with DriveWorks Administrator, but you do need to have run DriveWorks Administrator at least once before you will see the add-in in SolidWorks. This is because DriveWorks Administrator is responsible for registering the add-in when it is launched.

That's all there is to it - if you want to know more feel free to drop us a line, you can find our contact details on our website. Failing that, if you'd like clarification on something I wrote here, just post a comment.

P.S - Some of you may be wondering how DriveWorksXpress works on 64-bit Windows with SolidWorks x64 given that it uses a Microsoft Access database - that is definately a story for another time and possibly place.

Cool Stuff in DriveWorks 6

It was brought to my attention in a recent conversation, that unfortunately not everybody is using DriveWorks 6 yet - something that will hopefully change in the coming weeks and months as awareness of the new version grows.

We made a tonne of changes with this release, and whilst change can be a disruptive experience, we've tried to minimize this as much as possible, particularly to places that have traditionally been cause for confusion.

As an example, we changed a bit of terminology in this release - not because we had nothing better to do, but because it really needed changing, "Alternative Projects" now becomes "Additional Models" to reflect the fact that you can have multiple distinct assemblies created by a single project. "Lookups" have become "Data Tables" to make the distinction between defining a table of data, and the act of doing a lookup (using VLOOKUP or HLOOKUP) against that data table. We took some serious feedback when making these changes and decided that the new terminology would help to lower the bar for new customers, as well as clarifying certain areas for our existing customers.

Also different is the look and feel of DriveWorks - again, we've tried not to be too radical, just clean things up, give them a more modern lilt which is easier on the eye, and provide more on-screen information about the form and function of various options.

We've also slightly re-organized the task list to better reflect the workflow during a typical implementation.

And last, but certainly not least, we've added a huge number of features, some of the highlights are:

• Specification Test - this provides a complete diagnostic environment in which a specification can be performed, and the run-time state of the specification inspected: drilling down into constants, variables, export data sets, documents, and model rules on the fly to see at every stage what the result of completing a specification would be. Rules can be drilled-down in to; to provide a complete picture of a rule, its dependencies, their dependencies and so on. The target models can also be generated at each stage to compare with the expected results - all without ever finishing the specification!
• Rules Builder Take 2 - the rules builder has been rejigged to be as usable as possible, as well as having had features like Syntax Highlighting, Wizard->Rule->Wizard support and intelligent diagnostic features added.
• Intelligent Renaming - DriveWorks now supports intelligent renaming of constants, variables, and form controls - doing so automatically updates all the rules which depend on the form control/constant/variable/lookup to point at the new name, DriveWorks can scan and update ~130,000 rules per second on a fairly modest machine.
• Unlimited Undo/Redo - We've added support for unlimited levels of undo and redo, providing much greater freedom, especially when working with Forms.
• Integrated File Management - The once separate file management utility now has a new home inside DriveWorks Administrator itself, and sees a major update with some great new functionality and an intuitive user interface.
• Personal Web Edition - DriveWorks Administrator now has a single-user seat of DriveWorks Live built-in which requires no additional set-up and can be used for testing and evaluation purposes.

This is just a selection of some of the things I find most exciting about DriveWorks 6, but there are loads more - better drawings, better 64-bit support, better forms, better performance, vastly improved database architecture, etc etc etc.

So - I hope to see you all in the world of DriveWorks 6 soon, it's our most  intuitive and efficient platform to date, and once you've used it, you'll not want to go back to anything else. Even if I do say so myself.

Renaming Dimensions in SolidWorks, Take 2

Okay, turns out that if you add a menu item to any of the SolidWorks menus, the user can assign a shortcut key, e.g. "F2", so, I've updated my renaming tool to add a "Rename..." entry to the bottom of the Edit menu in SolidWorks as well as creating the pop-up menu item.

Once the tool is installed, you can use the Tools|Customize menu in SolidWorks to assign the shortcut key of your choice to the "Rename..." command listed for the Edit menu.

As before,  I've uploaded the utility, both in an installable form, and as source code (VB.NET 2005), and both are provided under the Microsoft Permissive License.

Thanks to Paul Gimbel for pointing me in the right direction on this one!

P.S. This has the rather neat side effect that the rename tool can be used in sketch mode. Hurrah!

Renaming Dimensions in SolidWorks

Okay - this one has very little to do with DriveWorks - while using SolidWorks, even the very small amount that I do, I like to name my dimensions something a bit more meaningful than D1, D2, D3, etc, but this is rather more time-consuming in SolidWorks than I think it needs to be so...

I wrote a small plug-in to SolidWorks that gives a "Rename..." command on the right-click menu of a dimension.

I would have liked to get it so you could select a dimension and press "F2" but I couldn't find anything in the API docs to deal with shortcut handlers, though I confess, I didn't exactly spend a lot of time on this project ;-), also, for some reason I can't fathom, the menu isn't shown when you right click a dimension in sketch mode. Go figure.

Anyway, if anyone finds it useful, I've uploaded the utility, both in an installable form, and as source code (VB.NET 2005), both are provided under the Microsoft Permissive License.

Just a quick note - renaming a dimension that you've already captured in DriveWorks is a bad idea ;-)

DriveWorks - Canada, Brazil, and other globalization stories...

DriveWorks is used by people all over the world, most of which never have a problem, but occasionally customers in come countries have trouble - hopefully I can explain why and how to get around it - but before I do, for once in my blogging career, let me start with the bottom line:

DriveWorks requires that your Windows regional settings match an installed language of Office Excel. For example, if you have a German version of Office, you are going to need to have German regional settings too.

The reason this seem to affect some people and not others is actually quite simple, in some parts of the world, it is common to have a bit of a mish-mash of languages installed on a machine - this normally happens in countries like Canada where multiple languages are spoken, or where multi-national companies are involved with a centralized IT purchasing process.

The other problem that can occur concerns languages used in multiple countries, for example Brazilian Portuguese and Austrian German spring to mind - the rule there is basically the same, make sure the settings for Office and your Windows region match - e.g. if you have a German version of Office, use German regional settings, not Austrian German.

We appreciate this can cause some frustration for affected customers, although once they know what the problem is, work-arounds are easy to devise.

It is also worth noting, that if your users are using DriveWorks Live to specify, the situation doesn't affect them because only the server needs the correct settings.

Unfortunately, the reason this comes about is due to an underlying bug in Microsoft Excel itself, and whilst we could code a work-around into DriveWorks, this would mean having to write English only rules. That seems the more evil of the two situations - why should we force everybody to write IF() rather than WENN(), ALS(), SI(), or one of the 37 other localized versions of Excel we support?

DriveWorks Live and IIS

We got an interesting e-mail sent to our support box today asking whether we had had any information comparing DriveWorks Live Server and Microsoft's Internet Information Services platform - the simple answer to which is, no, not really - but let me try to explain a bit more about Live Server and some of its history which should hopefully clear things up.

If you don't know already, IIS is Microsoft's web server technology which is designed for high scalability and extensibility, and according to one report from last October, serves around 54% of the fortune 1000's web sites.

So - how does DriveWorks Live stack up against that? well, it doesn't. More importantly, it isn't meant to. DriveWorks Live isn't so much a web server, as a platform for running DriveWorks implementations on the web - and it does this extremely well.

DriveWorks Live Server has been designed from the ground-up to run DriveWorks implementations as fast and scalably as possible, with the very unique requirements that DriveWorks implementations have. Most web sites involve serving up fairly static pages as fast as possible, possibly with some data driven content. DriveWorks implementations, on the other hand, involve highly dynamic forms with many changes throughout a single specification session, dynamic warnings, custom macro execution, processor and disk intensive finish; and release processes, heavy memory usage for rule evaluation, and a plethora of other very specialized requirements. All of which DriveWorks Live Server is custom written to manage as efficiently as possible.

In fact, DriveWorks Live delegates most of the technical gumpf required for a web server to something called HTTP.SYS which is the very same component that powers IIS itself. This component was originally built into IIS but with Windows XP Service Pack 2, and Windows Server 2003 Service Pack 1, Microsoft chose to move it into the Windows Kernel itself, increasing performance, and opening it up to third party application developers that wanted to have their web apps sit alongside IIS - if you draw it out it looks a bit like:

 

Where Proj1 and Proj2 are DriveWorks projects - also worthy of note is that IIS and DriveWorks Live can sit alongside each other perfectly happily, each on their own combination of IP Address, Port, and virtual directory (I'll discuss DriveWorks Live bindings another time). Also, IIS doesn't need to be installed for DriveWorks Live to work.

So - what is the bottom line? comparing DriveWorks Live Server and IIS is comparing apples and oranges. They both have a common web component, and after that, they are both designed for completely different purposes.

For anyone reading past the last paragraph, it is interesting to note that DriveWorks Live started off, back in days of yore, as an ASP.NET application running on top of IIS, which you may remember as DriveWorks .NET, but we quickly discovered the very specific requirements of DriveWorks necessitated a different approach.

(That isn't quite true but I'm sure you don't want to hear about the first ASP prototypes we were experimenting with in 2001 ;-)

What is DriveWorks Live?

Ah. Well. Uhm. Now you see, I think we describe what DriveWorks Live is pretty well if you know what DriveWorks itself is - after-all it isn't hard, it just takes your DriveWorks implementation, and makes it accessible using an internet browser such as Microsoft's Internet Explorer.

If only that was enough. The problem however is that a lot of people ask the question, and many of them aren't necessarily the guys that bought it - it's the IT guy, the marketing guy, the web site guy, and so on. So, this post is for you IT guys, and hopefully it'll help you understand a little of what all this activity is about. What this post isn't is an in-depth look at everything involved, it is just an overview.

First, a whirlwind description of DriveWorks itself in case you don't know - DriveWorks is an automation tool designed to be used by engineers to automate, well, engineering stuff. It consists of a few different bits and pieces - DriveWorks Administrator, DriveWorks User, DriveWorks Model-Generation Server, and DriveWorks Live Server, all of which talk to each other by way of a database.

The database will either be Microsoft Access if we are talking about upgrading from our entry-level package, or one of the editions of Microsoft SQL Server 2000 or 2005.

DriveWorks Administrator is used by the engineering guys to tell DriveWorks what to automate, and how to automate it.

DriveWorks User is used by anyone that needs to specify one of the automated designs.

DriveWorks Model-Generation Server sits in the background, monitoring the database to see if any designs have been specified and need automating, and then does whatever is needed to do the automation.

DriveWorks Live Server is kinda like DriveWorks User - it allows people to specify the automated designs, but it does so by making the automation available over the web.

From an IT stand-point there are a few things you need to be aware of, basically, like I said before - all the DriveWorks products talk to each-other by means of a database, so, one needs to be available somewhere. We've found the freely available SQL Server 2005 Express to be a great starting point for companies that don't already have SQL Server in-house, and for those that do - DriveWorks will sit quite happily on an existing server alongside other databases. Obviously this means the right ports have to be open in your database server firewall if they aren't already. This is very easy to do, and we have documents and guidance for the common situations.

The other thing is that DriveWorks is pretty much all about files, it creates a tonne of data so the engineering guys don't have to - this means having all this data available via a network share mapped to a local drive letter on each client machine. Now, for the most part it already is, and where it isn't, it is relatively trivial to set-up. But you need to think about permissions, and the firewall on the machine hosting the files - again, this is an easy enough task.

The only other high-level thing is that each machine using DriveWorks needs Microsoft Excel XP (2002) installed at a minimum, and it is advantageous to make sure that Office Web Components are installed as well (part of the Microsoft Office install).

Now - what does all this have to do with DriveWorks Live Server? well, everything really, you see if you more or less understand everything above - there's very little else to know, DriveWorks Live Server is an application just like DriveWorks Administrator et al. The only additional requirement is that you need to open a port for DriveWorks Live Server itself - now, by default, Live Server uses port 8020 (the reason why is one for another day) on all IP addresses, but you can change both the port and IP address to whatever you want. As long as the port is open, and the server is available to the people that need access - everything is okay.

If your Live Server machine is internet facing, obviously there is a little more thought involved in allocating an IP address, deciding on firewall configuration etc, but the bottom line is that as long Live Server has access to the database and the file server, everything will work a charm.

It is worth noting, DriveWorks Live Server doesn't need IIS or ASP.NET installed on the same machine, but we do require Windows Server 2003 SP1 or greater.

Hopefully that helps, but if you need any further clarification, our contact details are on our web site, or you can e-mail me directly - I can't guarantee a fast response but I'll do what I can.

Common Code Pattern #1 - MD5 Hash In .NET

There are some bits of code you end up writing dozens of times and showing other people how to write dozens of times more.

I thought I'd go through a few of the ones I come across frequently; to save other people the hassle of writing their own, which for first-time developers can sometimes seem a little bit counter-intuitive or daunting, and for the rest of us, well, we're just plain lazy ;-)

Public Shared Function HashPassword(ByVal password As String) As String

    Dim md5 As New System.Security.Cryptography.MD5CryptoServiceProvider()

    Dim bytes As Byte() = MD5.ComputeHash(System.Text.Encoding.UTF8.GetBytes(password)) 

    Dim result As New System.Text.StringBuilder() 


    For Each hashByte As Byte In Bytes

        result.Append(hashByte.ToString("X2") )

    Next 

    Return result.ToString()

End Function 

The above bit of code computes the MD5 hash of an input string, it looks like a bit more code than one might expect at first glance, but it is quite logical:

MD5, and other hash algorithms such as SHA1 (which is now more popular than MD5) take an input as a series of bytes, and produce as an output hash of a fixed length, also in byte form. So the bulk of the code above is transforming to and from bytes.

First, we take the input string (password), and convert it into a byte representation, there are a number of ways of doing this, some of which are:

• System.Text.Encoding.ASCII - one byte per character but doesn't support international characters such as ü ö ä etc
  
• System.Text.Encoding.Unicode - currently supports many tens upon tens of thousands characters from around the globe, but requires a minimum of 2 bytes per character.
  
• System.Text.Encoding.UTF8 - can encode many characters as 1 byte, and uses more where necessary, for the most part you can think of UTF8 as a compressed unicode format.

I highly discourage the use of ASCII in modern applications as internationalization is very important, if not now, then it will almost undoubtedly become an issue at some point.

Which of UTF8 and Unicode you use is up to you, when hashing it doesn't really matter as long as you are consistent - but when transmitting data the choice can matter more, if your audience is primarily using a latin alphabet, then UTF8 is probably the way to go, otherwise the Unicode encoding will serve better as the average number of bytes per character will be smaller for non-latin characters.

The rest of the code merely asks the MD5 provider to compute the hash, then enumerates the resulting bytes to build up a string, all the .ToString("X2") means is "convert the byte to a string made up of 2 hexadecimal digits". Lowercase x means lowercase hex digits, and uppercase X means uppercase hex digits.

DriveWorks Extensibility

I posted on my previous blog about extensibility but I just wanted to make the point again for anyone that didn't see it.

Extensibility is one of the coolest features in the latest version of DriveWorks - DriveWorks 6. It is possible to create plug-ins to DriveWorks which can do virtually anything that DriveWorks itself can - some examples being; adding support for PDM systems other than PDMWorks Workgroup and PDMWorks Enterprise, automating DriveWorks Server to create new specifications, automatic model printing, and a whole raft of others.

I published a draft some time ago of a walk-through of creating a very simple plug-in for DriveWorks, which at some point towards the end of this month I will update, but, for anyone that really wants to get started now - here you go:

http://www.philipstears.net/driveworks/plugintutorial.zip

It covers the very basics, and by the time I am finished it will hopefully walk-through all of the core components of the DriveWorks API from Configuration through to customising the specification process.

One thing is worth noting when it comes to DriveWorks - I firmly believe in a hands-off zero-programming approach, and I believe DriveWorks enables this in a way that no other solution in this space can boast. That said, we do appreciate that sometimes you just need to go the extra mile, and we try very hard to be as flexible as possible, hence extensibility and our support for macros.

As it turns out, zero is a relative term.

Changes of Scenery

Now, if I had just one pound sterling for every time I'd moved from one blog to another I'd have; well - about four pounds really. Granted - not that much, yet still, I feel more than necessary.

I won't labour any time on why I have moved my blog yet again, if you know me you have heard the spiel before, and if you don't - well, you probably aren't interested, and if you are, you should probably find something more entertaining to do with your life.

With that said, my remit for this blog is pretty much the same as in the past, to explore issues in and around DriveWorks (the product which I help design and develop), and the Microsoft .NET platform (which is what we design and develop it in).

So if that's what floats your boat, please feel free to stick around.