How to change the width of a floating pallete in DM scripting
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
add a comment |
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
add a comment |
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
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
dm-script
asked Nov 22 '18 at 6:54
kachigusakachigusa
767
767
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Be aware that the situation of floating palettes is different between
GMS 2.x
andGMS 3.x
.
Essentially, registered floating palettes are phased out inGMS 3.x
with the new UI. They are still supported to some extend, but not all functionality remains and some behavior is buggy. ForGMS 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)
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Be aware that the situation of floating palettes is different between
GMS 2.x
andGMS 3.x
.
Essentially, registered floating palettes are phased out inGMS 3.x
with the new UI. They are still supported to some extend, but not all functionality remains and some behavior is buggy. ForGMS 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)
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
add a comment |
Be aware that the situation of floating palettes is different between
GMS 2.x
andGMS 3.x
.
Essentially, registered floating palettes are phased out inGMS 3.x
with the new UI. They are still supported to some extend, but not all functionality remains and some behavior is buggy. ForGMS 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)
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
add a comment |
Be aware that the situation of floating palettes is different between
GMS 2.x
andGMS 3.x
.
Essentially, registered floating palettes are phased out inGMS 3.x
with the new UI. They are still supported to some extend, but not all functionality remains and some behavior is buggy. ForGMS 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)
Be aware that the situation of floating palettes is different between
GMS 2.x
andGMS 3.x
.
Essentially, registered floating palettes are phased out inGMS 3.x
with the new UI. They are still supported to some extend, but not all functionality remains and some behavior is buggy. ForGMS 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)
answered Nov 22 '18 at 10:20
BmyGuestBmyGuest
3,31711225
3,31711225
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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