How to change the width of a floating pallete in DM scripting












1















Now I'm trying to write a DM script to display a floating palette as shown in the following code. However, for example, a long string label as included in this code protrude from the palette window. So, I'm wondering how to change the palette window size (i.e, width in this case). Actually, some Gatan's official palette windows such as "Camera View", "Camera Acquire" etc. seem to be wider than the pallete created by this code. It will be appreciated if you share some wisdom. Thank you very much in advance.



Class MyDialog: UIFrame
{
TagGroup createDLGtgs( Object self ){
TagGroup DLGtgs, DLGItems
DLGtgs = DLGCreateDialog( "Test Dialog", DLGItems )
DLGItems.DLGAddElement( DLGCreateLabel( "Test of Gatan DigitalMicrograph scripting" ) )
DLGItems.DLGAddElement( DLGCreatePushButton( "OK", "testOK" ) )
return DLGtgs
}
//
Object Init( Object self ){
self.super.Init( self.createDLGtgs() )
return self
}
//
Void testOK( Object self ){
OKDialog( "Hello!" )
}
}
//
Object DialogOBJ = Alloc( MyDialog ).Init()
String DialogName = "Test Dialog"
String toolName = "Test Tool"
RegisterScriptPalette( DialogOBJ, DialogName, toolName )
OpenGadgetPanel(toolName)









share|improve this question



























    1















    Now I'm trying to write a DM script to display a floating palette as shown in the following code. However, for example, a long string label as included in this code protrude from the palette window. So, I'm wondering how to change the palette window size (i.e, width in this case). Actually, some Gatan's official palette windows such as "Camera View", "Camera Acquire" etc. seem to be wider than the pallete created by this code. It will be appreciated if you share some wisdom. Thank you very much in advance.



    Class MyDialog: UIFrame
    {
    TagGroup createDLGtgs( Object self ){
    TagGroup DLGtgs, DLGItems
    DLGtgs = DLGCreateDialog( "Test Dialog", DLGItems )
    DLGItems.DLGAddElement( DLGCreateLabel( "Test of Gatan DigitalMicrograph scripting" ) )
    DLGItems.DLGAddElement( DLGCreatePushButton( "OK", "testOK" ) )
    return DLGtgs
    }
    //
    Object Init( Object self ){
    self.super.Init( self.createDLGtgs() )
    return self
    }
    //
    Void testOK( Object self ){
    OKDialog( "Hello!" )
    }
    }
    //
    Object DialogOBJ = Alloc( MyDialog ).Init()
    String DialogName = "Test Dialog"
    String toolName = "Test Tool"
    RegisterScriptPalette( DialogOBJ, DialogName, toolName )
    OpenGadgetPanel(toolName)









    share|improve this question

























      1












      1








      1








      Now I'm trying to write a DM script to display a floating palette as shown in the following code. However, for example, a long string label as included in this code protrude from the palette window. So, I'm wondering how to change the palette window size (i.e, width in this case). Actually, some Gatan's official palette windows such as "Camera View", "Camera Acquire" etc. seem to be wider than the pallete created by this code. It will be appreciated if you share some wisdom. Thank you very much in advance.



      Class MyDialog: UIFrame
      {
      TagGroup createDLGtgs( Object self ){
      TagGroup DLGtgs, DLGItems
      DLGtgs = DLGCreateDialog( "Test Dialog", DLGItems )
      DLGItems.DLGAddElement( DLGCreateLabel( "Test of Gatan DigitalMicrograph scripting" ) )
      DLGItems.DLGAddElement( DLGCreatePushButton( "OK", "testOK" ) )
      return DLGtgs
      }
      //
      Object Init( Object self ){
      self.super.Init( self.createDLGtgs() )
      return self
      }
      //
      Void testOK( Object self ){
      OKDialog( "Hello!" )
      }
      }
      //
      Object DialogOBJ = Alloc( MyDialog ).Init()
      String DialogName = "Test Dialog"
      String toolName = "Test Tool"
      RegisterScriptPalette( DialogOBJ, DialogName, toolName )
      OpenGadgetPanel(toolName)









      share|improve this question














      Now I'm trying to write a DM script to display a floating palette as shown in the following code. However, for example, a long string label as included in this code protrude from the palette window. So, I'm wondering how to change the palette window size (i.e, width in this case). Actually, some Gatan's official palette windows such as "Camera View", "Camera Acquire" etc. seem to be wider than the pallete created by this code. It will be appreciated if you share some wisdom. Thank you very much in advance.



      Class MyDialog: UIFrame
      {
      TagGroup createDLGtgs( Object self ){
      TagGroup DLGtgs, DLGItems
      DLGtgs = DLGCreateDialog( "Test Dialog", DLGItems )
      DLGItems.DLGAddElement( DLGCreateLabel( "Test of Gatan DigitalMicrograph scripting" ) )
      DLGItems.DLGAddElement( DLGCreatePushButton( "OK", "testOK" ) )
      return DLGtgs
      }
      //
      Object Init( Object self ){
      self.super.Init( self.createDLGtgs() )
      return self
      }
      //
      Void testOK( Object self ){
      OKDialog( "Hello!" )
      }
      }
      //
      Object DialogOBJ = Alloc( MyDialog ).Init()
      String DialogName = "Test Dialog"
      String toolName = "Test Tool"
      RegisterScriptPalette( DialogOBJ, DialogName, toolName )
      OpenGadgetPanel(toolName)






      dm-script






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 22 '18 at 6:54









      kachigusakachigusa

      767




      767
























          1 Answer
          1






          active

          oldest

          votes


















          1















          Be aware that the situation of floating palettes is different between GMS 2.x and GMS 3.x.

          Essentially, registered floating palettes are phased out in GMS 3.x with the new UI. They are still supported to some extend, but not all functionality remains and some behavior is buggy. For GMS 3.x it is generally better to launch scripted dialogs as modal or modeless dialogs and no longer install them as palettes.






          This answer here is for GMS 2.x (Tested with GMS 2.3.3)



          You need to add position tags to the dialog-describing tagGroup. You do this in your example code of the question above by adding to the TagGroup createDLGtgs( Object self ) method:



          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsString( "Width", "Medium" )
          DLGtgs.DLGPosition( positionTgs )


          The string values accepted are:





          • "Small" Like the left-hand tool palettes of GMS 2.x.


          • "Medium" Like the right-hand tool palettes of GMS 2.x


          • "Wide" extra wide


          There are, however, a few addtional options for the position tags, but they will not apply to floating palettes, just to regular modeless dialogs. You can set the width and height of a window either with an absolute size value or let it be automatically determined by the size of the content. Here is an example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildAbsoluteSize( 45, "pixel" ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          Alloc(CMyClass).InitAndShow()


          In the above DLGBuildPositionFromApplication() sets the application window as the reference frame for the dialog. One can then define the position of the dialog left|center|right and top|center|bottom to that frame using the command DLGBuildRelativePosition() with -1|0|1 as respective parameter, like in the example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildAutoSize() )

          // Appear top-right
          positionTgs.TagGroupSetTagAsTagGroup( "X", DLGBuildRelativePosition( "Inside", 1 ) )
          positionTgs.TagGroupSetTagAsTagGroup( "Y", DLGBuildRelativePosition( "Inside", -1 ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          Alloc(CMyClass).InitAndShow()


          The reference-frame does not have to be the application window, though. You can specify any wanted using DLGBuildPosition(), which allows using f.e. a window rect and then placing the dialog right of it. And with the reference-frame, one can also size the dialog window relative to that using DLGBuildMatchSize() as in the following example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self, documentWindow win ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          number t,l,b,r
          win.WindowGetFrameBounds(t,l,b,r)
          TagGroup positionTgs = DLGBuildPosition(t,l,b,r)
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildMatchSize() )

          // Appear center-right outside the window
          positionTgs.TagGroupSetTagAsTagGroup( "X", DLGBuildRelativePosition( "Outside", 1 ) )
          positionTgs.TagGroupSetTagAsTagGroup( "Y", DLGBuildRelativePosition( "Inside", 0 ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          image img := RealImage("test",4,100,100)
          img.ShowImage()
          documentWindow win = img.ImageGetOrCreateImageDocument().ImageDocumentGetWindow()
          Alloc(CMyClass).InitAndShow(win)





          share|improve this answer
























          • Thank you very much for your detailed explanation. Actually I'm using a GMS2.3 system, and thus your advices were quite helpful for me. Concerning the difference between GMS1.x, GMS2,x and GMS3.x that you mentioned, I feel it is a troublesome problem. Now Although now I'm writing some handmade library scripts for GMS1.x and GMS2.x (and GMS3.x, if it is possible) systems, it seems that I should prepare different one for these different systems. Thank you again.

            – kachigusa
            Nov 23 '18 at 15:51











          • @kachigusa Between GMS 1 and GMS 2 only the commands of registering/Unregistering changed. The other stuff shoud work in both. (And one can use a trick to make code which can register in both versions.) GMS 3 is different though, because the UI does no longer have registered palettes at all. It uses "experiment" panes. The safest way for a script UI working in GMS 3 is to just launch it as modeless dialog.

            – BmyGuest
            Nov 23 '18 at 17:16











          • But yes, there comes a point where the differences between GMS 1 and GMS 2 and GMS 3 become simply to big to faciliate "all-around-compatibility". GMS 1 is already very old. It is a bit like now writing plugins which not only run on Win10 and Win7, but also on 32bit WinXP and even Win95....

            – BmyGuest
            Nov 23 '18 at 17:18











          • Thank you for your additional useful comments. I would like to agree that writing of a script with "all-around-compatibility" is an excessive goal. Under current situation, I feel that my target should be focused to GMS2.x systems (or include GMS1.x systems with small changing of the script).

            – kachigusa
            Nov 23 '18 at 18:57











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53425368%2fhow-to-change-the-width-of-a-floating-pallete-in-dm-scripting%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1















          Be aware that the situation of floating palettes is different between GMS 2.x and GMS 3.x.

          Essentially, registered floating palettes are phased out in GMS 3.x with the new UI. They are still supported to some extend, but not all functionality remains and some behavior is buggy. For GMS 3.x it is generally better to launch scripted dialogs as modal or modeless dialogs and no longer install them as palettes.






          This answer here is for GMS 2.x (Tested with GMS 2.3.3)



          You need to add position tags to the dialog-describing tagGroup. You do this in your example code of the question above by adding to the TagGroup createDLGtgs( Object self ) method:



          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsString( "Width", "Medium" )
          DLGtgs.DLGPosition( positionTgs )


          The string values accepted are:





          • "Small" Like the left-hand tool palettes of GMS 2.x.


          • "Medium" Like the right-hand tool palettes of GMS 2.x


          • "Wide" extra wide


          There are, however, a few addtional options for the position tags, but they will not apply to floating palettes, just to regular modeless dialogs. You can set the width and height of a window either with an absolute size value or let it be automatically determined by the size of the content. Here is an example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildAbsoluteSize( 45, "pixel" ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          Alloc(CMyClass).InitAndShow()


          In the above DLGBuildPositionFromApplication() sets the application window as the reference frame for the dialog. One can then define the position of the dialog left|center|right and top|center|bottom to that frame using the command DLGBuildRelativePosition() with -1|0|1 as respective parameter, like in the example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildAutoSize() )

          // Appear top-right
          positionTgs.TagGroupSetTagAsTagGroup( "X", DLGBuildRelativePosition( "Inside", 1 ) )
          positionTgs.TagGroupSetTagAsTagGroup( "Y", DLGBuildRelativePosition( "Inside", -1 ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          Alloc(CMyClass).InitAndShow()


          The reference-frame does not have to be the application window, though. You can specify any wanted using DLGBuildPosition(), which allows using f.e. a window rect and then placing the dialog right of it. And with the reference-frame, one can also size the dialog window relative to that using DLGBuildMatchSize() as in the following example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self, documentWindow win ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          number t,l,b,r
          win.WindowGetFrameBounds(t,l,b,r)
          TagGroup positionTgs = DLGBuildPosition(t,l,b,r)
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildMatchSize() )

          // Appear center-right outside the window
          positionTgs.TagGroupSetTagAsTagGroup( "X", DLGBuildRelativePosition( "Outside", 1 ) )
          positionTgs.TagGroupSetTagAsTagGroup( "Y", DLGBuildRelativePosition( "Inside", 0 ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          image img := RealImage("test",4,100,100)
          img.ShowImage()
          documentWindow win = img.ImageGetOrCreateImageDocument().ImageDocumentGetWindow()
          Alloc(CMyClass).InitAndShow(win)





          share|improve this answer
























          • Thank you very much for your detailed explanation. Actually I'm using a GMS2.3 system, and thus your advices were quite helpful for me. Concerning the difference between GMS1.x, GMS2,x and GMS3.x that you mentioned, I feel it is a troublesome problem. Now Although now I'm writing some handmade library scripts for GMS1.x and GMS2.x (and GMS3.x, if it is possible) systems, it seems that I should prepare different one for these different systems. Thank you again.

            – kachigusa
            Nov 23 '18 at 15:51











          • @kachigusa Between GMS 1 and GMS 2 only the commands of registering/Unregistering changed. The other stuff shoud work in both. (And one can use a trick to make code which can register in both versions.) GMS 3 is different though, because the UI does no longer have registered palettes at all. It uses "experiment" panes. The safest way for a script UI working in GMS 3 is to just launch it as modeless dialog.

            – BmyGuest
            Nov 23 '18 at 17:16











          • But yes, there comes a point where the differences between GMS 1 and GMS 2 and GMS 3 become simply to big to faciliate "all-around-compatibility". GMS 1 is already very old. It is a bit like now writing plugins which not only run on Win10 and Win7, but also on 32bit WinXP and even Win95....

            – BmyGuest
            Nov 23 '18 at 17:18











          • Thank you for your additional useful comments. I would like to agree that writing of a script with "all-around-compatibility" is an excessive goal. Under current situation, I feel that my target should be focused to GMS2.x systems (or include GMS1.x systems with small changing of the script).

            – kachigusa
            Nov 23 '18 at 18:57
















          1















          Be aware that the situation of floating palettes is different between GMS 2.x and GMS 3.x.

          Essentially, registered floating palettes are phased out in GMS 3.x with the new UI. They are still supported to some extend, but not all functionality remains and some behavior is buggy. For GMS 3.x it is generally better to launch scripted dialogs as modal or modeless dialogs and no longer install them as palettes.






          This answer here is for GMS 2.x (Tested with GMS 2.3.3)



          You need to add position tags to the dialog-describing tagGroup. You do this in your example code of the question above by adding to the TagGroup createDLGtgs( Object self ) method:



          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsString( "Width", "Medium" )
          DLGtgs.DLGPosition( positionTgs )


          The string values accepted are:





          • "Small" Like the left-hand tool palettes of GMS 2.x.


          • "Medium" Like the right-hand tool palettes of GMS 2.x


          • "Wide" extra wide


          There are, however, a few addtional options for the position tags, but they will not apply to floating palettes, just to regular modeless dialogs. You can set the width and height of a window either with an absolute size value or let it be automatically determined by the size of the content. Here is an example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildAbsoluteSize( 45, "pixel" ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          Alloc(CMyClass).InitAndShow()


          In the above DLGBuildPositionFromApplication() sets the application window as the reference frame for the dialog. One can then define the position of the dialog left|center|right and top|center|bottom to that frame using the command DLGBuildRelativePosition() with -1|0|1 as respective parameter, like in the example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildAutoSize() )

          // Appear top-right
          positionTgs.TagGroupSetTagAsTagGroup( "X", DLGBuildRelativePosition( "Inside", 1 ) )
          positionTgs.TagGroupSetTagAsTagGroup( "Y", DLGBuildRelativePosition( "Inside", -1 ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          Alloc(CMyClass).InitAndShow()


          The reference-frame does not have to be the application window, though. You can specify any wanted using DLGBuildPosition(), which allows using f.e. a window rect and then placing the dialog right of it. And with the reference-frame, one can also size the dialog window relative to that using DLGBuildMatchSize() as in the following example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self, documentWindow win ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          number t,l,b,r
          win.WindowGetFrameBounds(t,l,b,r)
          TagGroup positionTgs = DLGBuildPosition(t,l,b,r)
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildMatchSize() )

          // Appear center-right outside the window
          positionTgs.TagGroupSetTagAsTagGroup( "X", DLGBuildRelativePosition( "Outside", 1 ) )
          positionTgs.TagGroupSetTagAsTagGroup( "Y", DLGBuildRelativePosition( "Inside", 0 ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          image img := RealImage("test",4,100,100)
          img.ShowImage()
          documentWindow win = img.ImageGetOrCreateImageDocument().ImageDocumentGetWindow()
          Alloc(CMyClass).InitAndShow(win)





          share|improve this answer
























          • Thank you very much for your detailed explanation. Actually I'm using a GMS2.3 system, and thus your advices were quite helpful for me. Concerning the difference between GMS1.x, GMS2,x and GMS3.x that you mentioned, I feel it is a troublesome problem. Now Although now I'm writing some handmade library scripts for GMS1.x and GMS2.x (and GMS3.x, if it is possible) systems, it seems that I should prepare different one for these different systems. Thank you again.

            – kachigusa
            Nov 23 '18 at 15:51











          • @kachigusa Between GMS 1 and GMS 2 only the commands of registering/Unregistering changed. The other stuff shoud work in both. (And one can use a trick to make code which can register in both versions.) GMS 3 is different though, because the UI does no longer have registered palettes at all. It uses "experiment" panes. The safest way for a script UI working in GMS 3 is to just launch it as modeless dialog.

            – BmyGuest
            Nov 23 '18 at 17:16











          • But yes, there comes a point where the differences between GMS 1 and GMS 2 and GMS 3 become simply to big to faciliate "all-around-compatibility". GMS 1 is already very old. It is a bit like now writing plugins which not only run on Win10 and Win7, but also on 32bit WinXP and even Win95....

            – BmyGuest
            Nov 23 '18 at 17:18











          • Thank you for your additional useful comments. I would like to agree that writing of a script with "all-around-compatibility" is an excessive goal. Under current situation, I feel that my target should be focused to GMS2.x systems (or include GMS1.x systems with small changing of the script).

            – kachigusa
            Nov 23 '18 at 18:57














          1












          1








          1








          Be aware that the situation of floating palettes is different between GMS 2.x and GMS 3.x.

          Essentially, registered floating palettes are phased out in GMS 3.x with the new UI. They are still supported to some extend, but not all functionality remains and some behavior is buggy. For GMS 3.x it is generally better to launch scripted dialogs as modal or modeless dialogs and no longer install them as palettes.






          This answer here is for GMS 2.x (Tested with GMS 2.3.3)



          You need to add position tags to the dialog-describing tagGroup. You do this in your example code of the question above by adding to the TagGroup createDLGtgs( Object self ) method:



          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsString( "Width", "Medium" )
          DLGtgs.DLGPosition( positionTgs )


          The string values accepted are:





          • "Small" Like the left-hand tool palettes of GMS 2.x.


          • "Medium" Like the right-hand tool palettes of GMS 2.x


          • "Wide" extra wide


          There are, however, a few addtional options for the position tags, but they will not apply to floating palettes, just to regular modeless dialogs. You can set the width and height of a window either with an absolute size value or let it be automatically determined by the size of the content. Here is an example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildAbsoluteSize( 45, "pixel" ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          Alloc(CMyClass).InitAndShow()


          In the above DLGBuildPositionFromApplication() sets the application window as the reference frame for the dialog. One can then define the position of the dialog left|center|right and top|center|bottom to that frame using the command DLGBuildRelativePosition() with -1|0|1 as respective parameter, like in the example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildAutoSize() )

          // Appear top-right
          positionTgs.TagGroupSetTagAsTagGroup( "X", DLGBuildRelativePosition( "Inside", 1 ) )
          positionTgs.TagGroupSetTagAsTagGroup( "Y", DLGBuildRelativePosition( "Inside", -1 ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          Alloc(CMyClass).InitAndShow()


          The reference-frame does not have to be the application window, though. You can specify any wanted using DLGBuildPosition(), which allows using f.e. a window rect and then placing the dialog right of it. And with the reference-frame, one can also size the dialog window relative to that using DLGBuildMatchSize() as in the following example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self, documentWindow win ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          number t,l,b,r
          win.WindowGetFrameBounds(t,l,b,r)
          TagGroup positionTgs = DLGBuildPosition(t,l,b,r)
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildMatchSize() )

          // Appear center-right outside the window
          positionTgs.TagGroupSetTagAsTagGroup( "X", DLGBuildRelativePosition( "Outside", 1 ) )
          positionTgs.TagGroupSetTagAsTagGroup( "Y", DLGBuildRelativePosition( "Inside", 0 ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          image img := RealImage("test",4,100,100)
          img.ShowImage()
          documentWindow win = img.ImageGetOrCreateImageDocument().ImageDocumentGetWindow()
          Alloc(CMyClass).InitAndShow(win)





          share|improve this answer














          Be aware that the situation of floating palettes is different between GMS 2.x and GMS 3.x.

          Essentially, registered floating palettes are phased out in GMS 3.x with the new UI. They are still supported to some extend, but not all functionality remains and some behavior is buggy. For GMS 3.x it is generally better to launch scripted dialogs as modal or modeless dialogs and no longer install them as palettes.






          This answer here is for GMS 2.x (Tested with GMS 2.3.3)



          You need to add position tags to the dialog-describing tagGroup. You do this in your example code of the question above by adding to the TagGroup createDLGtgs( Object self ) method:



          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsString( "Width", "Medium" )
          DLGtgs.DLGPosition( positionTgs )


          The string values accepted are:





          • "Small" Like the left-hand tool palettes of GMS 2.x.


          • "Medium" Like the right-hand tool palettes of GMS 2.x


          • "Wide" extra wide


          There are, however, a few addtional options for the position tags, but they will not apply to floating palettes, just to regular modeless dialogs. You can set the width and height of a window either with an absolute size value or let it be automatically determined by the size of the content. Here is an example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildAbsoluteSize( 45, "pixel" ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          Alloc(CMyClass).InitAndShow()


          In the above DLGBuildPositionFromApplication() sets the application window as the reference frame for the dialog. One can then define the position of the dialog left|center|right and top|center|bottom to that frame using the command DLGBuildRelativePosition() with -1|0|1 as respective parameter, like in the example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          TagGroup positionTgs = DLGBuildPositionFromApplication()
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildAutoSize() )

          // Appear top-right
          positionTgs.TagGroupSetTagAsTagGroup( "X", DLGBuildRelativePosition( "Inside", 1 ) )
          positionTgs.TagGroupSetTagAsTagGroup( "Y", DLGBuildRelativePosition( "Inside", -1 ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          Alloc(CMyClass).InitAndShow()


          The reference-frame does not have to be the application window, though. You can specify any wanted using DLGBuildPosition(), which allows using f.e. a window rect and then placing the dialog right of it. And with the reference-frame, one can also size the dialog window relative to that using DLGBuildMatchSize() as in the following example:



          class CMyClass : UIFrame
          {
          void InitAndShow( object self, documentWindow win ) {
          Taggroup DLG,DLGItems
          DLG = DLGCreateDialog("Test",DLGItems)
          DLGItems.DLGAddElement( DLGCreateLabel( "Just some long text for extra width" ))
          DLGItems.DLGAddElement( DLGCreateLabel( "A second line" ))

          number t,l,b,r
          win.WindowGetFrameBounds(t,l,b,r)
          TagGroup positionTgs = DLGBuildPosition(t,l,b,r)
          positionTgs.TagGroupSetTagAsTagGroup( "Width", DLGBuildAutoSize() )
          positionTgs.TagGroupSetTagAsTagGroup( "Height", DLGBuildMatchSize() )

          // Appear center-right outside the window
          positionTgs.TagGroupSetTagAsTagGroup( "X", DLGBuildRelativePosition( "Outside", 1 ) )
          positionTgs.TagGroupSetTagAsTagGroup( "Y", DLGBuildRelativePosition( "Inside", 0 ) )
          DLG.DLGPosition( positionTgs )

          self.super.Init( DLG ).Display("Test")
          }
          }

          image img := RealImage("test",4,100,100)
          img.ShowImage()
          documentWindow win = img.ImageGetOrCreateImageDocument().ImageDocumentGetWindow()
          Alloc(CMyClass).InitAndShow(win)






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 22 '18 at 10:20









          BmyGuestBmyGuest

          3,31511225




          3,31511225













          • Thank you very much for your detailed explanation. Actually I'm using a GMS2.3 system, and thus your advices were quite helpful for me. Concerning the difference between GMS1.x, GMS2,x and GMS3.x that you mentioned, I feel it is a troublesome problem. Now Although now I'm writing some handmade library scripts for GMS1.x and GMS2.x (and GMS3.x, if it is possible) systems, it seems that I should prepare different one for these different systems. Thank you again.

            – kachigusa
            Nov 23 '18 at 15:51











          • @kachigusa Between GMS 1 and GMS 2 only the commands of registering/Unregistering changed. The other stuff shoud work in both. (And one can use a trick to make code which can register in both versions.) GMS 3 is different though, because the UI does no longer have registered palettes at all. It uses "experiment" panes. The safest way for a script UI working in GMS 3 is to just launch it as modeless dialog.

            – BmyGuest
            Nov 23 '18 at 17:16











          • But yes, there comes a point where the differences between GMS 1 and GMS 2 and GMS 3 become simply to big to faciliate "all-around-compatibility". GMS 1 is already very old. It is a bit like now writing plugins which not only run on Win10 and Win7, but also on 32bit WinXP and even Win95....

            – BmyGuest
            Nov 23 '18 at 17:18











          • Thank you for your additional useful comments. I would like to agree that writing of a script with "all-around-compatibility" is an excessive goal. Under current situation, I feel that my target should be focused to GMS2.x systems (or include GMS1.x systems with small changing of the script).

            – kachigusa
            Nov 23 '18 at 18:57



















          • Thank you very much for your detailed explanation. Actually I'm using a GMS2.3 system, and thus your advices were quite helpful for me. Concerning the difference between GMS1.x, GMS2,x and GMS3.x that you mentioned, I feel it is a troublesome problem. Now Although now I'm writing some handmade library scripts for GMS1.x and GMS2.x (and GMS3.x, if it is possible) systems, it seems that I should prepare different one for these different systems. Thank you again.

            – kachigusa
            Nov 23 '18 at 15:51











          • @kachigusa Between GMS 1 and GMS 2 only the commands of registering/Unregistering changed. The other stuff shoud work in both. (And one can use a trick to make code which can register in both versions.) GMS 3 is different though, because the UI does no longer have registered palettes at all. It uses "experiment" panes. The safest way for a script UI working in GMS 3 is to just launch it as modeless dialog.

            – BmyGuest
            Nov 23 '18 at 17:16











          • But yes, there comes a point where the differences between GMS 1 and GMS 2 and GMS 3 become simply to big to faciliate "all-around-compatibility". GMS 1 is already very old. It is a bit like now writing plugins which not only run on Win10 and Win7, but also on 32bit WinXP and even Win95....

            – BmyGuest
            Nov 23 '18 at 17:18











          • Thank you for your additional useful comments. I would like to agree that writing of a script with "all-around-compatibility" is an excessive goal. Under current situation, I feel that my target should be focused to GMS2.x systems (or include GMS1.x systems with small changing of the script).

            – kachigusa
            Nov 23 '18 at 18:57

















          Thank you very much for your detailed explanation. Actually I'm using a GMS2.3 system, and thus your advices were quite helpful for me. Concerning the difference between GMS1.x, GMS2,x and GMS3.x that you mentioned, I feel it is a troublesome problem. Now Although now I'm writing some handmade library scripts for GMS1.x and GMS2.x (and GMS3.x, if it is possible) systems, it seems that I should prepare different one for these different systems. Thank you again.

          – kachigusa
          Nov 23 '18 at 15:51





          Thank you very much for your detailed explanation. Actually I'm using a GMS2.3 system, and thus your advices were quite helpful for me. Concerning the difference between GMS1.x, GMS2,x and GMS3.x that you mentioned, I feel it is a troublesome problem. Now Although now I'm writing some handmade library scripts for GMS1.x and GMS2.x (and GMS3.x, if it is possible) systems, it seems that I should prepare different one for these different systems. Thank you again.

          – kachigusa
          Nov 23 '18 at 15:51













          @kachigusa Between GMS 1 and GMS 2 only the commands of registering/Unregistering changed. The other stuff shoud work in both. (And one can use a trick to make code which can register in both versions.) GMS 3 is different though, because the UI does no longer have registered palettes at all. It uses "experiment" panes. The safest way for a script UI working in GMS 3 is to just launch it as modeless dialog.

          – BmyGuest
          Nov 23 '18 at 17:16





          @kachigusa Between GMS 1 and GMS 2 only the commands of registering/Unregistering changed. The other stuff shoud work in both. (And one can use a trick to make code which can register in both versions.) GMS 3 is different though, because the UI does no longer have registered palettes at all. It uses "experiment" panes. The safest way for a script UI working in GMS 3 is to just launch it as modeless dialog.

          – BmyGuest
          Nov 23 '18 at 17:16













          But yes, there comes a point where the differences between GMS 1 and GMS 2 and GMS 3 become simply to big to faciliate "all-around-compatibility". GMS 1 is already very old. It is a bit like now writing plugins which not only run on Win10 and Win7, but also on 32bit WinXP and even Win95....

          – BmyGuest
          Nov 23 '18 at 17:18





          But yes, there comes a point where the differences between GMS 1 and GMS 2 and GMS 3 become simply to big to faciliate "all-around-compatibility". GMS 1 is already very old. It is a bit like now writing plugins which not only run on Win10 and Win7, but also on 32bit WinXP and even Win95....

          – BmyGuest
          Nov 23 '18 at 17:18













          Thank you for your additional useful comments. I would like to agree that writing of a script with "all-around-compatibility" is an excessive goal. Under current situation, I feel that my target should be focused to GMS2.x systems (or include GMS1.x systems with small changing of the script).

          – kachigusa
          Nov 23 '18 at 18:57





          Thank you for your additional useful comments. I would like to agree that writing of a script with "all-around-compatibility" is an excessive goal. Under current situation, I feel that my target should be focused to GMS2.x systems (or include GMS1.x systems with small changing of the script).

          – kachigusa
          Nov 23 '18 at 18:57


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53425368%2fhow-to-change-the-width-of-a-floating-pallete-in-dm-scripting%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          404 Error Contact Form 7 ajax form submitting

          How to know if a Active Directory user can login interactively

          Refactoring coordinates for Minecraft Pi buildings written in Python