Security

AWaterman · Post by **AWaterman** » Wed Jun 15, 2011 11:27 pm

A couple of questions which arise because I work in an organisation which has numerous security controls

1) does dplotlib come with the normal licensed dplot install dplotfull_setup.exe?
2) Is there a security reason why the install would not put dplotlib in the dplot addin directory?
3) When I do the naughty thing and drop a copy of dplotlib on the C drive, and try to add a reference to it from VBA, by browsing to it, I get "can't add a reference to the specified file". Is this a registry problem (no access to registry)?
4) the excel addin works OK (after I browsed to it). I presume it does not use dplotlib.dll. Correct?

The local thought police are actually quite cooperative, but I need to tell them exactly what they should be doing in order to allow me access to dplotlib.

AWaterman · Post by **AWaterman** » Thu Jun 16, 2011 12:57 am

And it is a local install. I should have mentioned this

Post by **DPlotAdmin** » Thu Jun 16, 2011 5:40 pm

1) No, mostly to try to keep the file size down (which is becoming increasingly futile, so I may change this.) and because most users don't care about that capability. DPLOTLIB.DLL is included with the DPlot Jr distribution and also as a separate download including example programs from http://www.dplot.com/lib/dplotlib.zip

Rewind after reading your #2: If you're talking about DPLOTLIB.XLA, YES, it is included in the distributions for DPlot Jr, the trial of the full version, and the full licensed version.

2) Now you have me confused. Are you talking about the Excel Add-In DPLOTLIB.XLA or the interface library DPLOTLIB.DLL (which the Add-In formerly used, but no longer does so that the Add-In will work with both 32- and 64-bit versions of Excel w/o swapping out DLL's)?

There are at least a couple of reasons why the Add-In might not show up in Excel:
a) DPlot was installed by an admin with a different user account, and the .xla file was copied to (for example on Windows 7) c:\users\<admin account>\AppData\Roaming\Microsoft\AddIns rather than c:\users\<user account>\AppData\Roaming\Microsoft\AddIns.

b) "Trust Center" settings. This will be labeled differently on versions of Excel older than 2007.

Just so we're clear, though, it isn't the dplot addin directory, it is the Excel Addins directory.

3) Adding a reference to DPLOTLIB.XLA won't do any good unless the AddIn has been properly installed (and thus shows up on the AddIns ribbon gizmo or the menu bar in Excel 2003 and earlier). It can definitely be done as long as the AddIn is properly installed and active, though. I have several spreadsheets that do this.

4) Yes, that is correct. It formerly did use the DLL, about a year ago. All of the functionality of DPLOTLIB.DLL (at least the parts used by the AddIn) were ported to VBA and moved inside the AddIn VBA code. This was done mostly to support 64-bit versions of Excel w/o having to distribute 2 versions of the DLL.

AWaterman · Post by **AWaterman** » Thu Jun 16, 2011 6:36 pm

My questions, inteded to clarify, just muddied the water. The XL side is all OK. I realise now that dplotlib.xla is what you get for the XL addin, and it doesn't need the dll. It just happens that on my personal laptop, where I am in control, and not the TP, dplotlib.dll appeared in the xl addins direcotry

What I really want is dplotlib.dll, so I can call it from with MS Access, and I realise now I have to get the TP to install it directly, as it does not come with the full version of DPLOT. I am also getting them to install DPLOT Jr on several machines, where this problem won't arise as the dll does come with it. With regard to telling them what to do.

Question 3 related to dplotlib.dll. I have a copy, I drop it on to my C drive in an area where I have write access, and I try then to add a reference to it from MS Access VBA, which is where I get the message about Can't add a reference

Sorry about the confusion. I think I was "thinking aloud" a bit.

When I say that I really want the dll. I want the dll AND the full dplot on some of these machines.

Post by **DPlotAdmin** » Thu Jun 16, 2011 7:00 pm

Les,

It just happens that on my personal laptop, where I am in control, and not the TP, dplotlib.dll appeared in the xl addins direcotry

That's only because you've been a user for a while and never bothered to uninstall when getting an update (which you don't need to do, but you do end up with a few stray files like this one).

Access and DPLOTLIB.DLL: Unfortunately I know next to nothing about Access, but I do know that "adding a reference" won't do anything other than report an error. That feature is intended for COM modules, which DPLOTLIB.DLL isn't. If the DLL is in a place where Access can find it this should not be a problem, in any case. The question is "where can it find it?". In older versions of the Excel Add-In I forced the current working directory to the folder where the .XLA file lived, which was also where the DLL was. And this was done any time an AddIn function was called and it worked fine (though conceivably if your own VBA routine is setting the working folder or relying on it being c:\whatever, this could have caused problems.)

I'll look into adding DPLOTLIB.DLL and all the example programs stuff to the setup for the full version. If it isn't too much bigger I'll probably make that a permanent change. But... you may not have picked up on this but you may be shooting yourself in the foot relying on the 32-bit DLL if your end users have 64-bit Access. You'll probably be better off porting the Excel VBA code to Access VBA. Not the Excel-specific AddIn functions but the underlying DDE code that communicates with DPlot. (Sorry, I have little idea how much might be involved with this suggestion, but I'm reasonably sure it is possible.)

Sorry about the confusion. I think I was "thinking aloud" a bit.

No reason to be sorry - no blood was spilled

AWaterman · Post by **AWaterman** » Thu Jun 16, 2011 7:33 pm

Thanks for the prompt response.

You are, of course, correct. I just went and checked how I had installed dplotlib (from dplotjr) with Access and it is where it can find it. You've given me a couple of options. I must be getting a bit vague.

It works just fine from Access, by the way.

I did think already about porting the dplotlib.xla code. Now I'll think some more, but in the short term, I'd like to use the dll.

AWaterman · Post by **AWaterman** » Thu Jun 16, 2011 9:14 pm

Problem solved. Put the dll somewhere central. Change all the declare ... dplotlib to the specific location.

Thanks for your help

Post by **DPlotAdmin** » Thu Jun 16, 2011 10:14 pm

I'd be very interested in seeing what you've done with Access, if only with a generic data set.

AWaterman · Post by **AWaterman** » Thu Jun 16, 2011 10:58 pm

I'll put something together and send you an email.

AWaterman · Post by **AWaterman** » Tue Jul 05, 2011 8:04 pm

Further to me moaning about our security - "they" have recently installed DPLOTJr on some machines, When I try to use the Excel add-in there, I get a message about "No Registry Entries for any of HKEY_CURRENT_USER..bla blah..DPLOTJr.

They a did a remote install. Is there some little thing they are not doing? (so I can tell them to do it.)

Thanks

Post by **DPlotAdmin** » Tue Jul 05, 2011 9:29 pm

Most likely the HKCU entry is under the Admin's account rather than "All Users" or the actual user. DPlot and DPlot Jr are self-correcting on this; if you run them they will write their location to the registry in the proper spot.

AWaterman · Post by **AWaterman** » Tue Jul 05, 2011 11:56 pm

Most likely you are correct, as you so often are.

However, the Thought Police here stop us from adding keys to the registry, so the self correcting action is thwarted. I think that's what is happening, as the message just repeats each time we run the addin.

I will attempt to get them to correct it.

Post by **DPlotAdmin** » Wed Jul 06, 2011 5:42 pm

It seems unlikely to me that your security restrictions would prevent a program from updating HKEY_CURRENT_USER. I'd think that this would break all sorts of things. The other possibility is you're running Excel under a different user account than you are dplot.exe or dplotjr.exe. If you're running Excel off of a network rather than your local machine... well, honestly I'm not sure how that works. But if you are, please let me know and we'll get to the bottom of this.

AWaterman · Post by **AWaterman** » Wed Jul 06, 2011 6:20 pm

I did wonder about that. I figured other stuff might want to write to HKEY_CURRENT_USER. Excel is installed on the same machine as DPLOTjr
here. This problem also occurs with the full DPLOT on one laptop - but that alos didn't seem to be licensed properly - another account problem?
The other two instances of DPLOT full version work fine.

I'll try and investigate any differences

Post by **DPlotAdmin** » Wed Jul 06, 2011 6:36 pm

Just as a sanity check, on a system where this is a problem run regedit. (Windows key+R, regedit.exe). You should see an entry under HKEY_CURRENT_USER/Software/DPLOTJR/shell/open/command with the default value set to the fully-qualified path to dplotjr.exe. If you don't and you've run dplotjr.exe on this system previously, then there likely is some crazy security setting preventing dplotjr.exe from writing to HKCU. (And if that's the case then... well, all hope is lost until I figure out a different way of finding dplotjr.exe.) If you do see that entry then for some strange reason the Add-In is looking in the wrong place. In that case I'll probably need to send you a modified Add-In that tells you exactly where it is looking.

If you tell me you can't run regedit.exe for security reasons I'll contribute to your kill-my-IT-folks fund

AWaterman · Post by **AWaterman** » Wed Jul 06, 2011 6:56 pm

They are generally nice people, between a rock and a hard place. It does become irritating though.

So I ran regedit before your reply, to look for the keys. They are not present on the machine with the problem, and they are on mine. ie no DPLOT section under software on the problem machine. I also see that when I look at the permissions for software, the local user has "full control". I tried to modify a key to check this and it worked. I did not try saving the modified registry.

What else could stop your addin from writing the key? (and why there and not on my machine, when we are supposed to have an SOE).

Post by **DPlotAdmin** » Wed Jul 06, 2011 7:19 pm

Just so we're clear, the Add-In does not write to the registry, it only reads it. What I was suggesting earlier was running dplotjr.exe - not from the Add-In. dplotjr (as well as the full version) should update the HKCU entry to show the correct path.

So...

On your problem machine, try running dplotjr.exe, then check the registry setting with regedit. All OK? If so, then the Add-In will almost certainly find it and all will be well. If it does not update the registry then we're back to square one and your security settings are more draconian than I can imagine.

If the registry setting is now correct (after running dplotjr.exe) and the Add-In still doesn't work, then the Add-In is looking in the wrong place. If that's the case please let me know, as that would mean I need to send you a modified Add-In that will give more specific error messages.

If running dplotjr.exe once fixes everything, then the problem is almost certainly that an Admin installed it under his user account. We can probably work around this, I just need to figure out what branch of the registry to use in the setup program. The fallback position if I can't figure that out is to instruct all users to run dplotjr.exe once before using the Add-In. But I would guess there's a better answer.

AWaterman · Post by **AWaterman** » Wed Jul 06, 2011 7:30 pm

Success.

I should learn to follow instructions.
I'd better call the dogs off the TP now

Thanks

Post by **DPlotAdmin** » Thu Jul 07, 2011 8:29 pm

Glad this all worked out, but if you get a chance ask the person who installed DPlot Jr whether he installed it under your account (doubtful) or his, or some "All Users" thing. I think this probably occurs more often than I know and I need to do something different in the setup program.

AWaterman · Post by **AWaterman** » Thu Jul 07, 2011 10:53 pm

I'll try to find out. Part of the problem is that the people who do it may not understand the question. If they did they might not do it - probably common in larger organisations