Topic: Paletteset startup location

[mohnston]

I can't seem to get my paletteset to start up in any location but docked on the left.
I've tried setting the Location property, the Dock property (see below) and many other combinations.
I would like it to start as a floating paletteset.

Code: [Select]

        static PaletteSet ps;
       
        public static void ShowPalette()
        {
            //
            if (ps == null)
            {
                ps = new PaletteSet("Finishes");
                ps.Style = PaletteSetStyles.ShowCloseButton |
                    PaletteSetStyles.Snappable |
                    PaletteSetStyles.ShowCloseButton |
                    PaletteSetStyles.ShowAutoHideButton;
                ps.MinimumSize = new System.Drawing.Size(420, 320);
                ps.Add("Finishes", new uControlAssign());
                ps.Dock = DockSides.None;
            }

            ps.Visible = true;
        }

It must be one of two things:
1. It is really simple and I'm a fool for not seeing it.
2. It is really simple but there is a bug so it doesn't work like you would expect.
Either way I'm going to hate the answer.

[It's Alive!]

you might try using a GUID

Code: [Select]

ps = new PaletteSet("Finishes" , new System.Guid("{E62F3B19-CD41-4814-A499-B2637A0090E8}"));

get your own Guid though 

[LE]

you might try using a GUID

Yep... same stuff I do... now just for test, don't load the DLL and open AutoCAD... do you get an error? on the command line, some unknown command?


Thanks~

[mohnston]

you might try using a GUID

Code: [Select]

ps = new PaletteSet("Finishes" , new System.Guid("{E62F3B19-CD41-4814-A499-B2637A0090E8}"));

get your own Guid though 

That works fine for subsequent starts but not the first start on a new system. But if that is as good as it gets then I'll take it.

How do I get my own Guid?
Is there an easy way to generate a Guid that would not be likely to get stepped on or step on?

[It's Alive!]

you should be able to generate one with System.Guid
dan

[mohnston]

you should be able to generate one with System.Guid
dan

Let me ask another way.
How did you come up with your GUID?

[TonyT]

you should be able to generate one with System.Guid
dan

Let me ask another way.
How did you come up with your GUID?

The best way to do it is not to generate a GUID but
instead, use the GUID of the class that is reponsible
for managing your palette:

Code: [Select]


public class MyPaletteManager
{
     [CommandMethod("MYSHOWCOMMAND")]
     public static void ShowMyPalette()
     {
          if( paletteSet == null )
          {
             paletteSet = new PaletteSet("MYSHOWCOMMAND",
                typeof(MyPaletteManager).GUID);
          }
         
          // show the paletteset, etc...
     }
     static PaletteSet paletteSet = null;
}



[mohnston]

Tony T
The best way to do it is not to generate a GUID but
instead, use the GUID of the class that is reponsible
for managing your palette:

Code: [Select]


public class MyPaletteManager
{
     [CommandMethod("MYSHOWCOMMAND")]
     public static void ShowMyPalette()
     {
          if( paletteSet == null )
          {
             paletteSet = new PaletteSet("MYSHOWCOMMAND",
                typeof(MyPaletteManager).GUID);
          }
         
          // show the paletteset, etc...
     }
     static PaletteSet paletteSet = null;
}



That worked like a charm Tony. Thank you.

I admit I don't know much about GUIDs, just that they provide the system with a way to uniquely identify programs (or is that objects?).

In the interest of understanding GUIDs better, what if my palette manager class had functions to create many palettes. Would I still be able to use the same class GUID like your example? Or would the system get confused as to which palette was being used?
For example:

Code: [Select]


public class MyPaletteManager
{
     [CommandMethod("MYSHOWCOMMAND")]
     public static void ShowMyPalettes()
     {
          if( paletteSet1 == null )
          {
             paletteSet1 = new PaletteSet("MYSHOWCOMMAND",
                typeof(MyPaletteManager).GUID);
          }
          // show the paletteset1, etc...
          if( paletteSet2 == null )
          {
             paletteSet2 = new PaletteSet("MYSHOWCOMMAND",
                typeof(MyPaletteManager).GUID);
          }
          // show the paletteset2, etc...
          if( paletteSet3 == null )
          {
             paletteSet3 = new PaletteSet("MYSHOWCOMMAND",
                typeof(MyPaletteManager).GUID);
          }
          // show the paletteset3, etc...

     }
     static PaletteSet paletteSet1 = null;
     static PaletteSet paletteSet2 = null;
     static PaletteSet paletteSet3 = null;
}



[TonyT]

Mark - Assuming you understand that the GUID is being used to
uniquely identify each PalletSet, it is really necessary to answer
this question?

I'm making stripped-down versions of some utility classes I use
to make working with PaletteSets easier (actually a breeze, or
at least compared to the crappy sample code Autodesk provides).

    http://www.caddzone.com/ExtensionApplicationBlock.zip

The project includes a class called PaletteSetFactory that acts
as a kind of "manager" for a PaletteSet (like I showed earlier),
and helps make building them brain-dead simple.

However, to understand that code and exploit it, one must
be able to think about coding in object-oriented terms, such
as consuming existing classes by deriving from them, rather
than creating instances of them.  Hopefully, this code will
not only help you build palettes easier, but also help you to
better understand how we solve problems in object-oriented
ways.

In the interest of understanding GUIDs better, what if my palette manager class had functions to create many palettes. Would I still be able to use the same class GUID like your example? Or would the system get confused as to which palette was being used?
For example:

Code: [Select]


public class MyPaletteManager
{
     [CommandMethod("MYSHOWCOMMAND")]
     public static void ShowMyPalettes()
     {
          if( paletteSet1 == null )
          {
             paletteSet1 = new PaletteSet("MYSHOWCOMMAND",
                typeof(MyPaletteManager).GUID);
          }
          // show the paletteset1, etc...
          if( paletteSet2 == null )
          {
             paletteSet2 = new PaletteSet("MYSHOWCOMMAND",
                typeof(MyPaletteManager).GUID);
          }
          // show the paletteset2, etc...
          if( paletteSet3 == null )
          {
             paletteSet3 = new PaletteSet("MYSHOWCOMMAND",
                typeof(MyPaletteManager).GUID);
          }
          // show the paletteset3, etc...

     }
     static PaletteSet paletteSet1 = null;
     static PaletteSet paletteSet2 = null;
     static PaletteSet paletteSet3 = null;
}



[Kerry]

Tony,
Thanks for publishing the 'PaletteSetFactory'.

That's very generous !

///kwb

[TonyT]

Tony,
Thanks for publishing the 'PaletteSetFactory'.

That's very generous !

///kwb

Quite welcome.  Hopefully those who find it
useful might reciprocate by letting me know
about any issues they may come across.

[mohnston]

Mark - Assuming you understand that the GUID is being used to
uniquely identify each PalletSet, it is really necessary to answer
this question?

I'm making stripped-down versions of some utility classes I use
to make working with PaletteSets easier (actually a breeze, or
at least compared to the crappy sample code Autodesk provides).

    http://www.caddzone.com/ExtensionApplicationBlock.zip

The project includes a class called PaletteSetFactory that acts
as a kind of "manager" for a PaletteSet (like I showed earlier),
and helps make building them brain-dead simple.

However, to understand that code and exploit it, one must
be able to think about coding in object-oriented terms, such
as consuming existing classes by deriving from them, rather
than creating instances of them.  Hopefully, this code will
not only help you build palettes easier, but also help you to
better understand how we solve problems in object-oriented
ways.

. . .

Tony,
I was hoping my question would prompt an explanation more than an answer. I was having a little trouble understanding why all of a sudden I was concerned with GUIDs. I have projects with multiple forms but have never needed to deal with GUIDs. Maybe this is something that Visual Studio was handling for me.

In any case your response and the code you made available is terrific. I am going to start looking at it today. I'll keep you posted with any comments.

Thank you. I really appreciate your willingness to share your experience and knowledge.

[TonyT]

Hi Mark.  It's kind self-explainatory and only
requires a little thinking, and my comment was
specifically related to your question about using
the same GUID to identify multiple PaletteSets.

Ignoring for the moment, the mechanics of a
GUID and were you get them from, and just
looking at them in purely conceptual terms, their
purpose is to act as a fingerprint of sorts, that
can be associated with something (anything)
that must be uniquely identifiable, and in a
predictable, and consistent manner.

GUID stands for Globally Unique IDentifier, and
if the purpose of using it here, is to uniquely
identify a PaletteSet then I think one can expect
nothing more than the use of a little common
sense to arrive at the conclusion that you can't
use the same GUID to uniquely identify more than
one PaletteSet.

 RIGHT?

As far as the backgrounder on what GUIDs are;
how the're constructed, and so on:

    http://en.wikipedia.org/wiki/Globally_Unique_Identifier

Regarding the sample code, after looking at it
better, I came to the conclusion that it is very
broken (in terms of design), and that it made
it too easy for misuse to lead to failure, so I've
ripped the entire thing apart and rebuilt it to be
a bit more robust.

See the updated version just posted, at the
same URL.

Mark - Assuming you understand that the GUID is being used to
uniquely identify each PalletSet, it is really necessary to answer
this question?

I'm making stripped-down versions of some utility classes I use
to make working with PaletteSets easier (actually a breeze, or
at least compared to the crappy sample code Autodesk provides).

    http://www.caddzone.com/ExtensionApplicationBlock.zip

The project includes a class called PaletteSetFactory that acts
as a kind of "manager" for a PaletteSet (like I showed earlier),
and helps make building them brain-dead simple.

However, to understand that code and exploit it, one must
be able to think about coding in object-oriented terms, such
as consuming existing classes by deriving from them, rather
than creating instances of them.  Hopefully, this code will
not only help you build palettes easier, but also help you to
better understand how we solve problems in object-oriented
ways.

. . .

Tony,
I was hoping my question would prompt an explanation more than an answer. I was having a little trouble understanding why all of a sudden I was concerned with GUIDs. I have projects with multiple forms but have never needed to deal with GUIDs. Maybe this is something that Visual Studio was handling for me.

In any case your response and the code you made available is terrific. I am going to start looking at it today. I'll keep you posted with any comments.

Thank you. I really appreciate your willingness to share your experience and knowledge.

[TonyT]

Let me ask another way.
How did you come up with your GUID?

Mark, In Visual Studio, do you have a
'Create GUID' item on the tools menu?

[mohnston]

Let me ask another way.
How did you come up with your GUID?

Mark, In Visual Studio, do you have a
'Create GUID' item on the tools menu?

Yes, I see it now. It has 4 options for creating GUIDs.

Thanks for the primer and wiki link.
I know this is off the original topic of palette sets but there may be other VB-to-C# people wondering the same thing I am.
A person can write entire programs without ever (knowingly) creating a GUID.
The program can have many dialogs with many controls. The system doesn't seem to have a problem keeping them straight.
For example the 3 palettes in my question cannot/should not have the same GUID. But I can create those 3 palettes without providing a GUID for any of them and they will work fine. Does the system work behind the scenes to generate the unique identifiers that it needs?

Under what circumstance would I want to generate a GUID instead of letting the system deal with identifiers?

[TonyT]

Mark - Have you ever wondered how AutoCAD remembers
where PalletteSets were docked, the size and position they
had in the last session?

It stores that information in a file, which is located in:

C:\Documents and Settings\<YourLoginName>\Application Data\Autodesk\AutoCAD 200X\RXX.x\enu\Support\Profiles\FixedProfile.aws

Find the file, and make a copy of it, and change the
extension of the copy to .XML and open it in IE or
another XML viewer, and take a look.

You'll see that tools are keyed to the GUIDs you
supply to the PalleteSet's constructor. If you don't
supply a GUID the I'm pretty sure that AutoCAD will
not persist the state of your PaletteSet.

Does the system work behind the scenes to generate the unique identifiers that it needs?

How can it do that, and associate it with a palletset
that only exists in your code?  The association is
established by passing the GUID to the PaletteSet's
constructor, which means that the GUID is actually
associated with the code that creates the PaletteSet,
not the PalletSet itself.

So, while anyone can generate a GUID, only your
code can tie it to the PaletteSet that it creates.

Important:

Contrary to what I suggested before, using the
GUID of a class is NOT a good idea.

That's because whenever you change your class
(e.g., add/remove a method; change a method's
signature, etc.), the GUID of your class changes. 

So, I have to wear egg here, because that is not
a good idea.

In the latest version of the library I posted, you
can apply a GUID attribute to the PaletteSet class
and the code will look for and use that instead of
the class's GUID.

[Kerry]

This is what's called the "Bleeding Edge", yes ?

[mohnston]

Tony,
Thanks a TON for the explanation. I can tell you I learned a lot from your comments. How much of it will stay in my leaky head is another story.
This part in particular caught my attention because I think it connects with something I already knew:

. . .
That's because whenever you change your class
(e.g., add/remove a method; change a method's
signature, etc.), the GUID of your class changes. 
. . .

Also known as "breaking compatability"?