VB.Net User Control can't find DPLOTLIB.dll

[engelbeck]

Hi David!

I wanted to thank you for making DplotJr available to hobbiest programmers like me for free! I am proud to be #8 on your members list. I think dPlot is the most capable plotting library available. I can't afford the commercial ones, but given the capabilities of dPlot, why would I want them?

I purchased the full version of Dplot ~5 years ago and have been struggling with using dPlotJr in my own programs ever since. I am programming in Visual Studio 2008 Team System (Trial Edition) using Visual Basic 2008 (.Net v3.5). I am trying to embed dplotJr into my own specialized software control to use in my own programs.

I used your VBnet Project2/4 examples as the template to my AnalysisViewerControl. When I test my AnalysisViewerControl, it finds DPLOTLIB.DLL in the call to your GLOBALS.vb module Sub Dplot_FindDPLOTLIB() without having to look into the registry.

However, my AnalysisViewerControl fails at runtime in the function call DPlot_Start(1,DPlotWasActive) with the error "Unable to load DLL 'dplotlib': the specified module could not be found. (Exception from HRESULT: 0x8007007E)

In disperation, I tried to add a reference to DPLOTLIB.DLL to my project. This produced the error "A reference to 'C:\Program Files\DplotJr\dplotlib\DPLOTLIB.DLL' could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component."

I searched through the DPlot forums and found one post in which you added DPlot_PlotNET as a very preliminary solution. I am assuming all of these updates got into your VB.Net examples...except that all of your VB.Net examples came across as "Upgrades" to VB6?

I am stummped. I can zip up my project and send it to you if you like..

Ranald M Engelbeck
Puyallup, Wa

[DPlotAdmin]

Ranald,
Thanks for your comments. You're welcome to send me your project, but that probably won't be necessary.

You definitely don't want to "Add a reference" to DPLOTLIB.DLL, as that feature is only for COM modules and the DLL isn't COM.

You may not have the most up-to-date source examples. In my globals.vb I have:

Code: Select all

Public Sub DPlot_FindDPLOTLIB()
    ' Find DPLOTLIB.DLL.
    Dim key As Microsoft.Win32.RegistryKey
    Dim path As String
    Dim hLib As IntPtr

    hLib = LoadLibrary("dplotlib.dll")
    If hLib <> 0 Then
        ' If LoadLibrary finds the DLL, then so will VB.NET, so there's
        ' no need to look in the registry or change the current
        ' directory
        FreeLibrary(hLib)
        Exit Sub
    End If

    key = Microsoft.Win32.Registry.CurrentUser.OpenSubKey("Software\\DPLOT\\DPLOTLIB\\Folder")
    path = key.GetValue("").ToString()
    key.Close()
    If Len(path) > 0 Then
        System.Environment.CurrentDirectory = path
    End If
End Sub

The only reason I can see for this to fail is if that registry entry isn't present. It is set when you install DPlot Jr, but if you've just moved things from one system to another then that key won't have been set.

You can manually set the key (HKEY_CURRENT_USER\Software\DPLOT\DPLOTLIB\Folder) to the folder where DPLOTLIB.DLL is located. Or if you're trying to write a setup script to distribute your app to others, here's the line in my Inno Setup script that does this (if you're using a different setup builder then of course the procedure may be a bit different):

Code: Select all

[Registry]
Root: HKCU; SubKey: "Software\DPLOT\DPLOTLIB\Folder"; ValueType: string; ValueData: "{app}\dplotlib"; Flags: uninsdeletekey

If the key IS set to the correct folder then something else is going wrong; please let me know in that case.

[DPlotAdmin]

Correction: You don't want to do this:

Code: Select all

[Registry] 
Root: HKCU; SubKey: "Software\DPLOT\DPLOTLIB\Folder"; ValueType: string; ValueData: "{app}\dplotlib"; Flags: uninsdeletekey 

in a setup program you're distributing to others, unless you're sending out your source that they'll run in the .NET environment. You do want to put DPLOTLIB.DLL in the same folder as your main executable, so that it will always find it w/o any special effort in your code.

[engelbeck]

David,
I un-installed DplotJr, deleted the directory, and re-instaled DplotJr day-before-yesterday so I think I have the most up-to-date examples. I did try to modify the code you had in your subroutine Dplot_FindDPLOTLIB.DDL with the following change:

hLib = LoadLibrary("C:\Program Files\DPlotJr\dplotlib\DPLOTLIB.DLL") '<---Here is my change
If hLib <> 0 Then
' If LoadLibrary finds the DLL, then so will VB.NET, so there's
' no need to look in the registry or change the current
' directory
FreeLibrary(hLib)
Exit Sub
End If

I did step through this code in the debuger and it did find DPLOTLIB.DLL inside this if statement. However, when it executed the function DPlot_Start(1,DPlotWasActive) it generated the error "Unable to load DLL 'dplotlib': the specified module could not be found. (Exception from HRESULT: 0x8007007E)

I looked in the registry at CurrentUser.OpenSubKey(HKEY_CURRENT_USER\Software\DPLOT\DPLOTLIB\Folder) , and it was pointing to the folder "C:\Program Files\DPlotJr\dplotlib", so in my opinion, even though your routine did not have to search the registry, it should have found DPLOTLIB.DLL if it had to.

I have never gotten past the development stage with my software so I have never moved or attempted to distributed it anywhere.

As far as putting DLPOTLIB.DLL in the same folder as my main executable, I am not certain where that is. The information I am sending you now is from within the Visual Studio 2008 IDE being tested in an OLE container. When it finally works there, my plan is to use the control from many programs and utilities.

Ron Engelbeck

[engelbeck]

David,
I tried putting a copy of DLPOTLIB.DLL in the bin/debug and bin/release folders of the AnalysisViewerControl project. When I did, it worked from within the OLE container....Yea! When I tried to run my test application for the software control it failed with my favorite error...you know "...can't find DLPOTLIB.DLL..." Well, I then copied DLOPTLIB.DLL into the bin/debug and bin/release folder of the test program and it now runs just fine.? Is there some way I can just hardwire the path to your DPLOTLIB.DLL in the dPlotJr installation folder "C:/Program Files/DplotJr/dplotlib/DPLOTLIB.DLL" ? What a mess having to install copies of the same DLL all over my system....and then have to update it...ouch!

Ron Engelbeck

[DPlotAdmin]

Ranald,
The only purpose of

Code: Select all

hLib = LoadLibrary("dplotlib.dll")
If hLib <> 0 Then
     ' If LoadLibrary finds the DLL, then so will VB.NET, so there's
     ' no need to look in the registry or change the current
     ' directory
    FreeLibrary(hLib)
    Exit Sub 
End If

is to test whether VB.NET can find the DLL w/o any other information. That block doesn't actually do anything, since it undoes LoadLibrary with FreeLibrary. When you subsitute the actual path, yeah LoadLibrary is successful, but then it throws that info away when you call FreeLibrary, and exits the routine (Exit Sub) w/o looking in the registry. (That's not to suggest you should delete the call to FreeLibrary; that isn't really the point.)

Neither here nor there, but none of this (including the registry setting) will be necessary when you build your exe and run it (as long as you follow my advice and copy DPLOTLIB.DLL to that same folder). The DPlot_FindDPLOTLIB subroutine and the registry setting are mainly a matter of convenience for testing your code within the VB.NET environment.

If for some reason you object to checking the registry and/or having DPlot_FindDPLOTLIB() set the working directory, you can copy DPLOTLIB.DLL to the \Windows\System folder and your code will work when run from within VB.NET. But I don't suggest doing that as it might end up making you forget to distribute the DLL or, just as bad in my opinion, convince you it should be installed on the end user's system to \Windows\System.

[DPlotAdmin]

Ranald,
Just a followup - after reading and re-reading my last reply I'm not sure I was clear.

The DPlot_FindDPLOTLIB routine is only included so that your code will work both within the VB.NET environment and as a standalone executable. If you only work with a standalone executable (what your end users will likely be doing unless you're distributing some sort of toolkit that includes your source code) then the call isn't necessary at all if DPLOTLIB.DLL is located some place that Windows will find it. The first place it looks (and my strong preference) is in the same folder as the executable.

If the DLL is located somewhere that Windows will find it then the call to DPlot_FindDPLOTLIB is unnecessary for your standalone executable, but won't hurt anything, either. If the DLL is located in the normal Windows search path for DLLs:

1. The directory from which the application loaded.
2. The current directory.
3. Windows 95 and Windows 98: The Windows system directory. Use theGetSystemDirectory function to get the path of this directory.
   Windows NT: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32.
4. Windows NT: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM.
5. The Windows directory. Use theGetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable.

(no, I didn't retype that from memory . That's from the MSVC Help file topic for LoadLibrary), then LoadLibrary will succeed and exit that routine. And subsequent calls to DPLOTLIB.DLL functions will work because we know that Windows can find the DLL w/o specifying the path.

The problem is with doing all this stuff within VB.NET, and is the reason for DPlot_FindDPLOTLIB in general and the registry setting specifically. The "directory from which the application loaded" is actually the folder for the VB.NET binaries, not your source. The second place Windows looks for DLLs is "the current directory", and that's what DPlot_FindDPLOTLIB is taking care of with the System.Environment.CurrentDirectory line. But that only works if the registry setting is present and correct (and if you don't circumvent what the source is trying to do by specifying the known path to DPLOTLIB.DLL in the LoadLibrary call so that the registry info is ignored )

I think that's about it. If you have any questions and of course if the original DPlot_FindDPLOTLIB doesn't work for you, please let me know.

[IceFisherman]

Hi David,

I have been using dplotjr periodically for almost 2 years now. It is a great product. I am currently trying to package the dplotjr files with my VB setup package for distribution, but I can't seem to find a way to elminate the "Wrong Version -- This program requires DPlot (or DPlot Jr) version 2.1.5.0 or later... currently using... None" If I install dplotjr on my test machine, the error goes away and everything works fine. However, I was hoping to avoid the user having to install my program and dplotjr.

The DPlot_FindDPLOTLIB command works correctly if I package the dplotlib.dll in the same folder as my executable as you suggested, but I still get the error in the DPlot_Start command. I believe I have followed all of the other distribution requirements correctly (include files, verify registry, etc.) I'm a novice programmer at best, so I may be missing something obvious?

Thanks a lot,

Josh

[DPlotAdmin]

Josh,

The "This program requires DPlot (or DPlot Jr) version 2.1.5.0 or later... currently using... None" statement is apparently correct in your case. DPLOTLIB.DLL doesn't perform any graphics operations; it only serves as an interface between your program and DPlot or DPlot Jr. Your end user must have one or the other installed on their system.

See the "Distribution" paragraph in the "Notes for DPlot Jr and DPlot Viewer users" topic in the Help file. If you have any questions after reading that please let me know.

[IceFisherman]

Hi David,

I posted several months ago about a problem I was having with packaging dplot files for re-distribution. I figured out how to package the dplotjr files along with my program using a VB setup package. I put the 6 required dplotjr files in the "Application Folder" on target machine and modified the user's registry with my application by adding the code between the *'s below to the "Form1_Load" function.

This has been working successfully on all the different types of user accounts on XP and standard Vista, but it does not work on Vista 64-bit. The only way I can get my program to work with DPlotJr on Vista 64-bit is to have the user also separately install DPlotJr. However, this will only work for the computer administrator and not on limited user accounts. I should also mentioned that the administrator account was not working successfully until I compiled my program using the X86 setting per advice on another thread regarding Vista 64-bit. As a test, I also compiled one of the VB example projects that is included with dplotjr with the X86 setting and it only worked successfully on the administrator account and with dplotjr also installed.

This may just be an issue with more restrictive permissions settings in Vista 64-bit (i.e. out of your control), but I wanted to give you heads-up in case anyone else is having trouble with this. Thank you very much for providing an excellent product and top notch support.

Josh

*******************************************
' Look up the dplotjr.exe registry value that was set during installation.
Dim DPlotjr_exe_path As String

DPlotjr_exe_path = _
My.Computer.Registry.GetValue("HKEY_USERS\.DEFAULT\Software\DPLOTJR\shell\print\command", _
"", "").ToString()

'Set the registry value so DPlotJr will find its own program files.

My.Computer.Registry.SetValue("HKEY_CURRENT_USER\Software\DPLOTJR\shell\open\command", "", DPlotjr_exe_path)
*******************************************

' Find DPlotJr libraries and program files
DPlot_FindDPLOTLIB()

...

[DPlotAdmin]

Josh,
Thanks for all of your comments.

I think I have the answer, though w/o Vista 64 I can't confirm this. I hate suggesting things I can't test, but...

When you call DPlot_Start (whether directly or by calling some other function) it looks first at HKEY_CURRENT_USER\Software\DPlot\shell\open\command. For a non-admin who has never run DPlotJr and for whom DPlotJr was installed by an admin, this will fail. But when it fails, it will then look in HKEY_LOCAL_MACHINE\Software\DPlot\shell\open\command. If you set that key in your setup program that is run by an admin, DPLOTLIB.DLL should be able to find DPLOTJR.EXE. (He says, crossing his fingers.) To set that key will require that the setup program be run by an admin, but it sounds like you're already forcing that anyway.