Hi Owen,
I thought I would get in first with this one. Apologies for being so quick off the mark after the AutoCAD 2014 release.
I was just wondering if a Runtime Installer will soon be issued that registers Opendcl on to AutoCAD 2014's registry for use in our deployments in the usual way?
Just asking because I'm presuming no arx recompile is required for this new release of CAD.
Many thanks
As soon as I figure out how to work around the new trusted path feature in 2014, I'll upload the new build. Hopefully this weekend, but I can't be certain.
Thought that would probably be the case.
If you can find a way to do it before AutoCAD is launched (or installing directly into the Autodesk\\ApplicationPlugins folder), I would be most interested.
Not least because the issue also affects the smooth operation of your lovely Lsploader too.
I've decided that for OpenDCL Runtime, it will add it's own path to TRUSTEDPATHS when it loads. I'll use a different approach for ManuSoft .arx modules, because I think appending paths to TRUSTEDPATHS will eventually create a huge mess.
Thanks Owen,
I'm now thinking the easiest way, is just to install the lspload modules into the ApplicationsPlugins Folder. Then use the loader's lisp file to silently add my application, odcl runtime or (anything else, as required) to the TRUSTEDPATHS.
What a completely pointless step by Autodesk this is.
any word when this will be ready for 2014?
The current development build includes support for AutoCAD 2014.
well it doesnt work then
ive installed the current release and its not working for me
are there any special instructions im missing?
Quote from: andrew on May 02, 2013, 07:15:56 AM
well it doesnt work then
ive installed the current release and its not working for me
are there any special instructions im missing?
You need to be more specific than "it doesn't work". Explain what you did, what you expected to happen, and what actually happened.
what i did
i uninstalled the previous version, as i always do when upgrading versions.
clicked on the .msi file, ODCL studio version 7.0.0.12.
it installed fine.
i launched acad2014 and i get the following on the opening of acad:
; error: no function definition: DCL_PROJECT_LOAD
what i expect to happen:
i install ODCL, launch acad and my programs work.
If you get an error when you launch AutoCAD, then you must have some code running at startup that is attempting to call OpenDCL functions before OpenDCL Runtime is loaded. Please trying entering the OPENDCL command manually after AutoCAD is started to ensure that it loads correctly (it should display status information at the command line when it loads). If it does not load correctly on demand, check the value of your DEMANDLOAD system variable. If OpenDCL does load correctly when you use the OPENDCL command, then you'll need to debug your code to see why it fails at startup.
my secureload variable was set to 2
so whatever ODCL needs to get passed that variable setting to allow for running, in the secure mode, it isnt successful at doing.
Sorry, I don't understand. Is the OPENDCL command working or not?
yes it is now
only because i have set the secureload variable to 0 instead of 2
when this variable is set to 2, it will not let it load.
I recommend to leave SECURELOAD set to 2.
leaving secureload at 2 will not let odcl load (for me)
i have to change it to 0 first, close acad, install the runtime then
relaunch acad and after verifying that odcl directory is added to the trusted path, i then can reset the secureload.
this is how it works for me, maybe this will come in handy for someone else that might have this issue
Sorry, I meant leave it set to the default value of 1, not 2.
Wasn't sure whether to start a new thread but I have the same problem but only on a machine running Windows XP.
OpenDCL loads and runs fine on Windows 7 and Windows 8. When run on XP using (command "opendcl") I get a return of nil.
I'm running XP 64 bit and Windows Update is telling me that I am up to date.
I've loaded OpenDCL using Appload and I get a return of "OpenDCL Runtime [7.0.0.12] loaded OpenDCL.x64.19.arx successfully loaded." When I type (command "opendcl") I'm still getting nil when I should be getting OpenDCL Runtime [7.0.0.12] loaded.
Quote from: macuma on May 14, 2013, 12:54:19 AMWhen I type (command "opendcl") I'm still getting nil when I should be getting OpenDCL Runtime [7.0.0.12] loaded.
Strange. What happens if you just enter the OPENDCL command directly without calling the (command) function?
A blank command line is returned.
I suggest you start a new thread. It's difficult to tell from what you've posted whether your problem is related to the new SECURELOAD system in AutoCAD 2014.
Does anyone have any idea how to override this message?
The first load the application it will appear 2 times.
Thanks velasquez
I got around it by having my app automatically adding the "...Common Files//OpenDCL//" folder to AutoCAD 2014's "TrustedPaths" variable prior to the first load of the Opendcl runtime module.
Quote from: Danner on June 12, 2013, 02:49:47 AM
I got around it by having my app automatically adding the "...Common Files//OpenDCL//" folder to AutoCAD 2014's "TrustedPaths" variable prior to the first load of the Opendcl runtime module.
Have you ever thought of working with AutoLoader and an xml file from Autodesk?
For the record, I don't recommend adding the OpenDCL runtime directory to the support path without the user's permission. I think it's better to do that *after* the user has consented to loading rather than before, which is how OpenDCL Runtime is designed to work.
Quote from: velasquez on June 12, 2013, 05:02:50 AM
Have you ever thought of working with AutoLoader and an xml file from Autodesk?
I'm more of a Bricscad man really. I use a single installer in conjunction with Owen's "LspLoader" for my deployments across all platforms of AutoCAD/BricsCAD.
Quote from: owenwengerd on June 12, 2013, 07:54:25 AM
For the record, I don't recommend adding the OpenDCL runtime directory to the support path without the user's permission. I think it's better to do that *after* the user has consented to loading rather than before, which is how OpenDCL Runtime is designed to work.
Fair point. (For what its worth - I should say my app is installed via a digitally signed installer).
Owen,
Would you consider digitally signing the opendcl.19.arx modules instead of adding Opendcl to the "TrustedPaths" in AutoCAD 2014?
This would be a more legitimate way to allow us to obtain a silent first install than the method I suggested.
Quote from: Danner on June 13, 2013, 01:01:23 AM
Owen,
Would you consider digitally signing the opendcl.19.arx modules instead of adding Opendcl to the "TrustedPaths" in AutoCAD 2014?
This would be a more legitimate way to allow us to obtain a silent first install than the method I suggested.
Hello Danner,
See the link below'm studying the same method.
Maybe this is the way.
http://adndevblog.typepad.com/autocad/Downloads/CP2080_PAL.pdf
vleasquez
Quote from: Danner on June 13, 2013, 01:01:23 AM
Would you consider digitally signing the opendcl.19.arx modules instead of adding Opendcl to the "TrustedPaths" in AutoCAD 2014?
That was considered and ruled out. The problem is that (in order to not violate the open source principle) the signing key would need to be made public by including it in the source code repository. However, doing so would make it easy for malicious users to sign their code with our key.
There is also a philosophical case to be made that third party developers should not insulate Autodesk from the problems it created. IOW, if users don't want the security warnings, let them hold Autodesk to the fire. If we as developers try to fix it once, we'll "own" it forever.
Quote from: velasquez on June 13, 2013, 05:47:34 AM
Hello Danner,
See the link below'm studying the same method.
Maybe this is the way.
http://adndevblog.typepad.com/autocad/Downloads/CP2080_PAL.pdf
vleasquez
Hi Velasquez,
Thanks for the link. That is indeed an excellent method. For once Autodesk have simplified things. So much easier to install your ".bundle" into a static "ApplicationPlugins" folder and edit a PackageContents.xml file. No need to touch the Windows Registry, Acaddoc.lsp etc. There are no horrible messages when your app is loaded for the first time from the "ApplicationPlugins".
From my perspective, because I support older AutoCAD platforms and Bricscad - I may as well continue with the traditional installer approach (which makes the necessary registry entries within Bricscad/Autocad to allow useage of Lsploader).
Now that AutoCAD 2014 has created TrustedPaths. My app now loads the relevant LspLoader files for AutoCAD 2014 into a new ".bundle" folder in the "ApplicationPlugins" folder. So for me, paradoxically things have actually got slightly more complicated deployment wise but has the advantage that I can use the same installer for deployments across all CAD platforms.
Quote from: owenwengerd on June 13, 2013, 09:00:07 AM
That was considered and ruled out. The problem is that (in order to not violate the open source principle) the signing key would need to be made public by including it in the source code repository. However, doing so would make it easy for malicious users to sign their code with our key.
There is also a philosophical case to be made that third party developers should not insulate Autodesk from the problems it created. IOW, if users don't want the security warnings, let them hold Autodesk to the fire. If we as developers try to fix it once, we'll "own" it forever.
Thanks Owen,
I had a feeling it was something to do with being open source.
I get your point I think that the security warnings are between Autodesk and their users and we developers shouldn't try and take ownership of this issue by finding ways to circumnavigate them. (I realize that is in direct contradiction of my previous reply).