** Note this solution only works in Windows and requires CSO extensions
supplied by Mercury Interactive. You can FTP to the site and get them, or go through
tech support and ask.

I have been working with WinRunner for a little less than a year after working with
Silk. I have noted that the way WinRunner expects the user to fully qualify dll's and
GUI files is preety brain dead!

This is one more barrier that causes creation of non-portable tests and I don't care for it.
I have seen very competent programmers write test scripts like so:

Which are essentially useless on another machine with a mirror image QA project (from
source safe) on a different drive or subdirectory.

The load_dll should in my opinion automatically search the system path in Windows. This convention
has existed for I dunno like 8 years now.

The GUI Load could either have a seperate supported path, or tack it's logic on the
module search path which WinRunner supports.

Such that if say for the machine in question the system path has:

And a searchpath like so (mercury delimits searchpath with <>:
(where the GUI map repository is appended to the end via Settings-> general options >> tab to folder )

Then you can write code like so with these functions:
load_dll_sp ("qa_dlls");

Where the set system path, and the WinRunners search path can vary from machine to machine
and still get resolved. Helping create more portable less ugly code.

In any case I have written up two functions (load_dll_sp and GUI_load_sp) that do just this.
They both REQUIRE the entire set of CSO extensions (provided by MI):

PLEASE DON'T ask me about this so called nameing convention. When working with Mercury Interactive
you will note "nameing conventions" really don't exist.

Here is the code that you can squirrel away in any compiled module that you think is central to
your organization.

Apologies if this has been done somewhere else. Please feel free to use and or modify this code in any way. Let me know if you have any feedback about this topic.