Topic: Persist Paletteset

[SEARAVEN]

Problem: Unable to persist a Paletteset from session to session (asuming it was resident on exit). Think I have read through all the relevent posts and I'd swear I had it working at one point, BAD is the command used to invoke the application and ps is a shared paletteset.

This is a result of converting the application to be compatible with .NET for AutoCAD 2014 and is an application which we have been using for years (including a persistent palette) since release 2009 I believe.
 
Here's my code:
 
Public Shared Sub Show()
      If ps Is Nothing Then
            ' (Command As String [Used when AutoCAD restarts to 'show' the palette if it was
            ' visible when the user quit], Tool ID As System GUID)
            ps = New PaletteSet("BAD", New Guid("8DC38958-1CBF-4CE7-AEE0-7C98BA84BDAB"))
            ps.MinimumSize = New Drawing.Size(400, 600)
            ps.Style = PaletteSetStyles.NameEditable Or PaletteSetStyles.ShowPropertiesMenu _
                           Or PaletteSetStyles.ShowAutoHideButton Or PaletteSetStyles.ShowCloseButton
            If File.Exists("C:\Pacificorp\pcorp.ico") Then ps.Icon = New Icon("C:\Pacificorp\pcorp.ico")
            ps.Name = "Drawing Batch Audit 2014"
            ps.Add("Drawing Batch Audit 2014", bad_control)
      End If
      ps.Visible = True
End Sub

One weird thing that's occuring (a new development or something I've just been missing) is that AutoCAD does seem to be issuing the command to start the application, however it seems to be doing so before the code is netloaded by our startup Lisp S::Startup function (see below). 
 
AutoCAD menu utilities loaded.
Loading [C:\Users\P28867\documents\autocad development\lisp\Pacificorp.Lsp]
Command: COMMANDLINE
Command: _RIBBON
Command: BAD
Unknown command "BAD". Press F1 for help.
Command:
Command: Substation CUIX IS Loaded... Member [P28867] Development Users...
NOT Copying Network files...
JB-Netloading: C:\Users\P28867\Documents\Visual Studio 2010\Projects\Pcorp\bin\Debug\PCorp.Dll
JB-Netloading: C:\Users\P28867\Documents\Visual Studio 2010\Projects\Pcorp_FXUpdate_2010\bin\Debug\FXUpDate.DLL
Not Copying XML files Locally....
Command:
Loading AeciIb...
Loading AeciUiBase...
Loading AeciIbApi...
Loading AeciRibbonUiApi...
Command:
 
The bold lines above show that AutoCAD is issuing the command to startup the application correctly (the Command name is 'BAD' and the application isn't loaded until the S::startup executes four lines below).  Please ignore the prompts about not loading support files that's just something I'm doing for development only.
 
The weird thing in all this is it used to work flawlessly and we have been using this application for years.  This particular issue grew out of converting the code over to the new ARX code requirments for AutoCAD 2013/ 2014.  Prior to that if the palette was visible (docked or floating) when Autocad was shut down it came back up in that position every time.

Any help gratefully solicited . . .

[n.yuan]

I saw the same question you posted earlier in Autodesk forum, but hesitated to respond, because I really do not what does it mean by "Unable to persist a PaletteSet from session to session". Do you mean:

In current session your PaletteSet is open, user may change its size/dock state. Then user close and restart AutoCAD, when open the PaletteSet, its size/dock state does not remain as it was when it was open last time?

If the PaletteSet was assigned an unchanged GUID (such as your code shows), AutoCAD should be able to persist the PaletteSet's state between sessions. Besides the size/dock state, AutoCAD also should remember whether the PaletteSet was visible or not in previous session.

I suspect the real issue with you is that when you restart AutoCAD session, you saw AutoCAD calls your "BAD" command automatically and then reports "Unknown command" (so, it is real BAD command  ).This is due to following reasons:

1. When you close AutoCAD with your PaletteSet open, AutoCAD does persists the PaletteSet's state (because the PaletteSet has a fixed GUID). When AutoCAD session starts again, it remembers that your PaletteSet was open previously, if the PaletteSet is created with constructor PaletteSet(string name, Guid id) or PaletteSet(string name, string cmd, Guid id);

2. There constructors with 2 arguments is a bit strange: the first string argument is both the PaletteSet name and the command that is used to open it.

So, in your case, if you want your PaletteSet behaces like AutoCAD built-in ones (Layer Manager, Design Center...), which has a command specified in the constructor, so that AutoCAD can automatically opens it if it was open in previous session, you need to preload your DLL or make your DLL load on demand, so that the command that opens your PaletteSet is available when AutoCAD tries open it automatically.

If you do not really need to let AutoCAD opens your PaletteSet just because it was open in previous session, you can specify a blank string in the PaletteSet constructor, which had been pointed out by someone's reply to your post in Autodesk discussion forum:

ps=New PalettSet("", New Guid(....))

or

ps=New PaletteSet("My BAD Palette Set","", New Guid(...))

This way, AutoCAD will not try to open your PaletteSet automatically upon its starts.

[SEARAVEN]

Thanks for your reply and yes your analysis of my problem is 100% the application (which has been in use for years) previously did behave just like any other AutoCAD palette (layers or properties or our custom tool palettes) and I have not changed the initialization code virtually at all.

The constructor I'm using (currently and which was the orignal version in the previous code) is:
ps = New PaletteSet("Batch Audit 2014 V2.5", "BAD", New Guid("8DC38958-1CBF-4CE7-AEE0-7C98BA84BDAB"))

And as you say AutoCAD is obediently storing the paletteset data and attempting to re-invoke it again in the next session so I guess my core question becomes why do I now need to preload the application (or demandload it) when loading it in the Lisp S::Startup has worked just fine for years?

[SEARAVEN]

SOLUTION:

As pointed out by n.yuan I needed to preload my application, why this is so in release 2014 when simply netloading it in our S::startup function has worked for years is still a mystery.

However after coming accross the code from Balaji_Ram in the Autodesk .NET forum (http://forums.autodesk.com/t5/NET/AutoCAD-2014-Automatic-dll-loading/td-p/4580115) and implementing it to register my app. the problem is solved and my paletteset is persisting it's state from session just as it used to. 

Thanks to everyone for their help.

[WILL HATCH]

sounds like you didn't use it with 2013.  When they abstracted the core functions out it changed the order of some start up functions.


My network deployment consists of 2 parts, first there is a program which is configured to run at autocad start which checks for a newer version of the config file and dll for the second program which is demand loaded.

My recommendation here is to take another step from lisp and do you config through .net, you can either create a .bundle (easiest in the long run) or add registry entries.

[SEARAVEN]

Nope, went straight from MAP2011 directly to MAP2014, must have missed the documentation which talked about a change in the start-up functions.

Yes I think you're right and creating a bundle will ultimately be the best solution (especially since we also contract a large number of consultants who also use the application), unfortunately I'm a bit under the gun at the moment and need to temporarily support multiple releases (2011 and 2014) and this function to register the application is a great solution.