TheSwamp

Code Red => .NET => Topic started by: RICVBA on August 25, 2015, 10:57:29 AM

Title: Autoloader
Post by: RICVBA on August 25, 2015, 10:57:29 AM
I'm in search for a fast way of testing&debugging AutoCAD plugins made in VSE2015 for Autocad 2014, trying to avoid that boring "netload -choose path&file- type command" procedure.

I thought Autoloader (http://adndevblog.typepad.com/autocad/2013/01/autodesk-autoloader-white-paper.html (http://adndevblog.typepad.com/autocad/2013/01/autodesk-autoloader-white-paper.html)) could be a solution, where I should deploy my "application" once, specifying the proper path (the usual "...\Documents\VisualStudio\Projects\myProject\debug\") to the fresh .dll to be netloaded every time a debug session starts Autocad

Is anyone already aware it is possible?

Or which other solution is possible/better?

thank you
Title: Re: Autolader
Post by: Keith Brown on August 25, 2015, 11:54:46 AM
If you are just using it for testing and debugging then modifying the registry for me is the way to go.  The tools by Gile here (http://www.theswamp.org/index.php?topic=31867.msg538136#msg538136) make that very easy.  If you are looking for a distribution solution then the autoloader would work better in that situation in my opinion. 


The reason why I don't use the autoloader all the time is I would need to copy the dll or dlls to the autoloader directory each time i modified them.  Now i could use visual studio to automate this but I prefer to just use Gile's tools to install and uninstall the dll when needed.  I have a separate dll with commands that will do that for me.

Title: Re: Autolader
Post by: BlackBox on August 25, 2015, 01:56:04 PM
I'm a big fan of the Autoloader mechanism, and use it for both app deployment, and interim debug\release testing.

For the latter, simply setup an Autoloader .bundle, and in your Visual Studio Project's Properties, specify the relative path for where the PackageContent.xml file is loading your compiled Assembly (see ModuleName XmlProperty for the appropriate ComponentEntry).

This automagically creates the necessary Registry entries for you at debug launch, and the next time the application is started (in or outside of VS), any Autoloader assembly not found is cleared from AutoCAD's Registry for you.

The only real gotcha with Autoloader 'residue' comes from the replicating of .CUIx/.MNR files from the .bundle itself into each-and-every-single product's ..\Support\ folder. Grrr

Cheers
Title: Re: Autolader
Post by: Keith Brown on August 25, 2015, 02:35:16 PM
I forgot to mention that I sometimes have a second autocad running to do extra miscellaneous operations.  Using the Autoloader in this scenario makes it a little more difficult as AutoCAD will lock down the dll.  Being able to uninstall in one version but having it running in another is a big plus for me.  The autoloader makes this difficult to achieve without constantly copying directories/files.
Title: Re: Autolader
Post by: Jeff H on August 25, 2015, 03:03:59 PM
I just use the Autoloader that loads an add-in that checks folders if files have been updated and if so copies them and then netloads them.
Title: Re: Autoloader
Post by: RICVBA on August 26, 2015, 02:57:42 AM
@Keith Brown:
I made it with Gile's tool! (I must have made some mistakes...)
Now I'd like to have proper command already sent to Autocad as weel so that after launching debug I'm straight on my way at the first breakpoint
how is ět possible?

to install/uninstall dll selectively for different Autocad sessions do you filter autocad product keys via "GetAllProductKeys()" method?
I guess this could be possible with different Autocad releases only

@BB:
If I got it right, the Autoloader and Keith-Gile's ways acts similarly to my needs: in both cases I must take care of uninstalling what I don't need anymore (removing assemblies form Autoloader Directory vs running Uninstall() method).
but I'm quite worried/annoyed with that  "Autoloader 'residue'": what is this exactly?

@Jeff
through your way, do you suffer the BB 'reside' issue?


thank you all
Title: Re: Autoloader
Post by: BlackBox on August 26, 2015, 11:08:38 AM
Autoloader 'residue' are files that remain even after successful uninstallation of an app you've formally downloaded from Autodesk Exchange, or tested of your own making - and only if you've included .CUIx and/or .MNR files (a requirement to publish an app at Autodesk Exchange).

This is an inherent 'benefit' of the Autoloader mechanism, and applies to any, and all Autoloader apps, regardless of your procedure to compile and update an Autoloader app's .bundle's assemblies.

The only way to avoid this issue (and again, only if using .CUIx or .MNR files), is to NOT use Autoloader at all.
Title: Re: Autoloader
Post by: BlackBox on August 26, 2015, 11:17:59 AM
Autoloader 'residue' are files that remain even after successful uninstallation of an app you've formally downloaded from Autodesk Exchange, or tested of your own making - and only if you've included .CUIx and/or .MNR files (a requirement to publish an app at Autodesk Exchange).

This is an inherent 'benefit' of the Autoloader mechanism, and applies to any, and all Autoloader apps, regardless of your procedure to compile and update an Autoloader app's .bundle's assemblies.

The only way to avoid this issue (and again, only if using .CUIx or .MNR files), is to NOT use Autoloader at all.

More information here:

http://adndevblog.typepad.com/autocad/2013/01/autodesk-autoloader-white-paper.html (<-- see comments at bottom)

http://forums.autodesk.com/t5/net/packagecontents-xml-update-from-2013-to-2014/m-p/3872842#M34603
Title: Re: Autoloader
Post by: RICVBA on August 27, 2015, 06:26:21 AM
Thank you  BB
As for now I don't use CUI and/or MNR files (at least for what I'm aware of ...)
So I'll give Autoloader way a try, too.

Skipping for a while (if I get feedbacks I'll start a new topic) to another argument I thought I saw a very fine topic in the swamp net thread about how to design an application for Autocad. It mainly investigated the high level design of it before jumping into some coding details (but not that many). I remember it was attended by the most clever of swamp guys and probably all of you here.
well, I'd like to get to that topic again but I couldn't make it till now. It should have started some 6 to 12 months ago and may not have had a proper topic title.
Maybe someone of you can help me getting that topic.
This since I actually want to code for an Autocad application that make use of a new a palette to help the user "build" his objects with predifined properties and methods through multiple sessions (thus needing to save and retrieve infos between them

thank you
Title: Re: Autoloader
Post by: BlackBox on August 27, 2015, 10:37:43 AM
You're welcome; I'm happy to help. :beer:

I choose to use Autoloader, despite the .CUIx byproduct (which doesn't affect how an app performs at all), because of how simple it is for me to quickly debug/deploy an app, each-and-every-single time I decide to create a new plug-in after reading a forum, or just generally have a new idea for an app - methinks you'll find it (Autoloader) to be beneficial as well.



as for the PaletteSet threads, not sure what you're looking for specifically, but here are two recent threads that come to mind:

Converter Palette (http://www.theswamp.org/index.php?topic=49358.0)

Zero Document State and Custom Tool Palettes (http://www.theswamp.org/index.php?topic=46316.0)
Title: Re: Autoloader
Post by: RICVBA on August 27, 2015, 12:57:25 PM
Thank you BB
I'll have a thorough look at the second link
As for the first one  I already read it once and started wondering whether to quit Winforms for wpf.  I searched the web and ended up with the thought wpf should stay for desktop apps and could also help for new standard winRT which seems bound to rule for mobiles and web.
what are your thoughts about this subject?


Title: Re: Autoloader
Post by: BlackBox on August 27, 2015, 02:21:50 PM
As for the first one  I already read it once and started wondering whether to quit Winforms for wpf.

Boo WinForms, Hooray WPF! :-D



*In before MexicanCustard*
Title: Re: Autoloader
Post by: MexicanCustard on August 28, 2015, 07:43:18 AM

Boo WinForms, Hooray WPF! :-D

*In before MexicanCustard*

Sweet, another convert!  Soon I'll have you all using WPF and Winforms will go the way of the dinosaur.
Title: Re: Autoloader
Post by: Keith Brown on August 28, 2015, 08:46:06 AM
Winforms is not dead!  Still making a lot of money using this supposedly dead and archaic technology!
Title: Re: Autoloader
Post by: dgorsman on August 28, 2015, 09:34:03 AM
For those just starting, yeah - WPF is the way to learn.  Me, I learned on Winforms, they function, and juggling too many things to get enough large blocks of time to learn.  Whatever works, right?   ;-)
Title: Re: Autoloader
Post by: MexicanCustard on August 28, 2015, 03:17:09 PM
Winforms is not dead!  Still making a lot of money using this supposedly dead and archaic technology!


Every time you use Winforms a puppy gets eaten in the far east. :cry:

Seriously though, good luck with those Winforms when you have to move to Universal Apps.
Title: Re: Autoloader
Post by: Jeff H on August 28, 2015, 03:35:45 PM
With WPF  I like to put all the code in the window class because everyone you do a mvvm purist dies a little.  :devilsidesmile:

Title: Re: Autoloader
Post by: RICVBA on August 30, 2015, 03:22:23 PM
I looked at "Zero Document State and Custom Tool Palettes" link given by BB in replay#9
I went through TT's "PaletteSetWithCloseEvent" extension successfully (i.e.: it ran!)
then I tried the same with Keith Brown's "EnhancedPaletteSet" extension class but I got stuck quite near (I guess) the endline: in my VSE2105 Error List window there showed three errors only, all with the same 'Code' (CS0103) and 'Description' ("The name 'Active' does not exist in the current context")
the three lines responsible for those errors are:
Code: [Select]
if (Active.Document == null)
Code: [Select]
if (documentCollection.Count > 1 && Active.Document != null)
Code: [Select]
if (documentCollection.Count == 1 || Active.Document == null)
I searched in theswamp NET forum with "Active.Document" keyword but all posts it put out just used "Active" as if it was a component/field/class granted for sure.
Also Google search didn't end up with any result
so I'm asking you where should I search for this topic?

thank you
Title: Re: Autoloader
Post by: Keith Brown on August 30, 2015, 03:51:15 PM
Oops.  Active is just a class I use to get the active document, database, etc.  just replace with the mdiactivedocument.
Title: Re: Autoloader
Post by: Kerry on August 30, 2015, 04:55:51 PM
RICVBA,


Have a look at the downloadable material from Scott McFarlane's AutoDesk University class lecture
http://au.autodesk.com/au-online/classes-on-demand/class-catalog/2013/autocad/dv2177#chapter=0


You'll find this Class source code  in Active.cs
I'd assume Keith's usage is similar  With references to the namespace this class is defined in.


Code - C#: [Select]
  1. using Autodesk.AutoCAD.ApplicationServices;
  2. using Autodesk.AutoCAD.ApplicationServices.Core;
  3. using Autodesk.AutoCAD.DatabaseServices;
  4. using Autodesk.AutoCAD.EditorInput;
  5.  
  6.  
  7. namespace DV2177.Common
  8. {
  9.     /// <summary>
  10.     /// Provides easy access to several "active" objects in the AutoCAD
  11.     /// runtime environment.
  12.     /// </summary>
  13.     public static class Active
  14.     {
  15.         /// <summary>
  16.         /// Returns the active Editor object.
  17.         /// </summary>
  18.         public static Editor Editor
  19.         {
  20.             get { return Document.Editor; }
  21.         }
  22.  
  23.  
  24.         /// <summary>
  25.         /// Returns the active Document object.
  26.         /// </summary>
  27.         public static Document Document
  28.         {
  29.             get { return Application.DocumentManager.MdiActiveDocument; }
  30.         }
  31.  
  32.  
  33.         /// <summary>
  34.         /// Returns the active Database object.
  35.         /// </summary>
  36.         public static Database Database
  37.         {
  38.             get { return Document.Database; }
  39.         }
  40.  
  41.  
  42.         /// <summary>
  43.         /// Sends a string to the command line in the active Editor
  44.         /// </summary>
  45.         /// <param name="message">The message to send.</param>
  46.         public static void WriteMessage(string message)
  47.         {
  48.             Editor.WriteMessage(message);
  49.         }
  50.  
  51.  
  52.         /// <summary>
  53.         /// Sends a string to the command line in the active Editor using String.Format.
  54.         /// </summary>
  55.         /// <param name="message">The message containing format specifications.</param>
  56.         /// <param name="parameter">The variables to substitute into the format string.</param>
  57.         public static void WriteMessage(string message, params object[] parameter)
  58.         {
  59.             Editor.WriteMessage(message, parameter);
  60.         }
  61.       }
  62. }
  63.  




   
Title: Re: Autoloader
Post by: Keith Brown on August 30, 2015, 05:21:37 PM
Yes,  that's definitely the one.  I have made a couple small changes to the class but the original I got from Scott's class.
Title: Re: Autoloader
Post by: RICVBA on August 31, 2015, 01:50:53 AM
thank you all
I downloaded the course and I'll get through it as soon as possible
Hope it will bring me one step further on the knowledge of the Transaction/OpenMode stuff and the likes
Title: Re: Autoloader
Post by: BlackBox on August 31, 2015, 11:58:49 AM
Hope it will bring me one step further on the knowledge of the Transaction/OpenMode stuff and the likes

Generally speaking -

Transactions are essentially a mechanism to simplify the way we interact with DBObjects, and when wrapped within a 'using' block, all of the overhead you'd otherwise have to manually manage, is handled for you with a simple call to Commit().

You can do everything that the using block, and Transaction do for you - the trade off is better performance, but more work on your part, with the added potential for fatal crashes if not managed properly.
Title: Re: Autoloader
Post by: RICVBA on August 31, 2015, 02:42:09 PM
I see

generally speaking can there be put a limit (number of database record, number and/or type of operations on them, other...) above which the better performance trade off is or can be actually worth the risk for fatal crashes?

I'm aiming at the awareness that for my actual uses it will never be
Title: Re: Autoloader
Post by: BlackBox on August 31, 2015, 03:14:25 PM
I see

generally speaking can there be put a limit (number of database record, number and/or type of operations on them, other...) above which the better performance trade off is or can be actually worth the risk for fatal crashes?

I'm aiming at the awareness that for my actual uses it will never be

I'll have to defer to someone more experienced than I to answer that, as I've been **perfectly happy with the performance of using Transactions + using block, and have never even tried - figured I'd leave that for the to-do list when I decide to step up into ObjectARX (C++ for AutoCAD).



** What I've not been happy with is Civil 3D-specific Objects not having sufficient .NET API exposure, to allow me to obtain the information I need without exploding in memory (not actually exploding the source Object), which is incredibly inefficient, just so to cull the information I'm after; example: Alignment Station Offset Labels. Grrr