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?