Dialog-Library - Wishlist

[PureLust]

Hi Fred,

once one get used to the the XML-Dialog Commands, they become really handy.
Especially when you design Apps with changeable Window-Size.
But I have 2 little requests:

1. Would it be possible, to add an option, to ignore the width/height of an invisible Gadget during your calculation for the dialog dimensions?

e.g.: In a program are several container which the user can fold (hide/unhide) by clicking a Button.
If you just hide them via HideGadget(), the dimension of the hidden Gadgets are still included in the RefreshDialog() calculation and the region just stays blank.
In an automatic Gadgetposition-Arrangement - like the XML-Dialog does, it would be great if it cloud ignore invisible gadgets and rearrange the visible Gadgets as if the invisible Gadgets are just not there.

As an example, you may have a look at THIS part of a XML-Dialog Designer I'm working on right now. You could fold/unfold the Container by clicking the (-/+) Buttons on the left side of the Headers.



To realize this fold/unfold feature, I have to close the whole dialog and reopen it with a changed XML-Code (without the tags for the container and all of it's gadgets).
As you can see, this results in an unpleasant Window-Close / Window-Open.

If the size of an invisible Gadget will be calculated as zero, a HideGadget() and RefreshDialog() would do the job.


2. GridBox - change number of columns after Dialog has been opened

As you can also see in the example from above, I change the number of displayed icons in a row when the user changes the width of the window.

To do so, I just have to change the number of columns in the <GridBox>.
But again ... one has to close the dialog, change the number of columns in the XML-Code and reopens the Dialog - which results in this Window-Olose / Window-Open effect again.

Would it be possible to implement an option to change the number of columns (or even other Parameters of the XML-Layout Elements) after creating the Dialog?


2.1 Maybe you could provide us with an insight into your Dialog-Structure, so the (experienced) user would be able to add/remove Gadgets 'on the fly'
E.g.: In the Dialog-Designer example from above - the user could add/remove Gadgets to the Emelent-List.
So far I don't see a way to realize this, without closing the Dialog, adding the new Elements to the XML.Code and reopening the whole Dialog again.
Adding new Elements (Gadgets) to the Element-Container 'on the fly' using the PB-Gadgets-Commands isn't the problem, but (so far) these new Gadgets will not be recognized by your Dialog-Routines and therefore they will not be handled by them.

Thanks a lot for all of your great work,
Albert.

[Andre]

+1

Sounds like very useful improvements to the Dialog lib.

[Didelphodon]

And I'd like to see the lib supporting menus and statusbars. Just wanted to entirely switch to the dialog concept for my ProcDOT project but had to find out that menus and statusbars are not supported. Bad luck, would have been the perfect solution for my cross-platform-GUI-problem which I'm currently facing

UPDATE: I'd be already happy if there were 2 extra flags for the windows-tag indicating a menu/statusbar/both to be considered in the auto-computations (size, arrangement, layout, resizing).

[pwd]

And I'd like to see the lib supporting menus and statusbars.

+1

We need ToolBar, Menu, StatusBar, plus OpenGLGadget support added to Dialog library.

[Kukulkan]

I support all suggestions here. The XML Dialogs need improvement as they are very handy. I use them for all dialogs

[Andre]

I support all suggestions here. The XML Dialogs need improvement as they are very handy. I use them for all dialogs

Another suggestion:
It would be perfect, if there would be also the possibility to update/change the Dialog definition when the Dialog is already opened.
Currently you have RefreshDialog() for forcing a re-calculation of the dialog dimensions, according to updated/extended gadget contents.

But if you want to remove / add some gadgets from the dialog you need to close the dialog (window) first and then re-open it using the updated declaration.

Now it would be open, if you could "send" an updated dialog definition to the dialog window, which automatically updates the displayed gadgets without closing/re-opening the window (which doesn't look very professional for the end user...).

[tj1010]

Both PB and SB need to scale bitmaps with container for dialog lib to do what it's intended.

Basically we need to be able to make width or height variable(think what happens when you rotate android screen there are such cases with x86 OSs too just resize a browser window) where it is past-aspect-radio of a new width or height and scale and adjust event coordinates and geometry for all children.

[PureLust]

Both PB and SB need to scale bitmaps with container for dialog lib to do what it's intended..

Indeed, such a feature would be nice to have.

Nevertheless you could realize resizeable Images within Dialogs.
But because PBs ImageGadget does not support automatically Bitmap resizing, you have to do the resize on your own.

To prohibit that the Dialog-Library uses the Image-Size to calculate the Dialog-Size, you must create a container instead of the ImageGadget and insert the ImageGadget into the container AFTER you create the Dialog.

Please have a look at the following example to see how to realize resizeable Images within a Dialog.

Code: Select all

XIncludeFile "..\DynamicDialogs\DynamicDialogs_plain.pbi"		; please adjust include-path

Enumeration ;Gadgets
	#gad_Spacer1
	#gad_Spacer2
	#gad_Spacer3
	#gad_Spacer4
	#gad_Container
	#gad_Image
EndEnumeration

Enumeration ;Images
	#SourceImage
	#DisplayImage
EndEnumeration

CreateImage(#SourceImage,800,600)				; ----- create an example-image
If StartDrawing(ImageOutput(#SourceImage))
	Box(0,0,800,600,#Blue)
	Circle(400,300,200,#Red)
	StopDrawing()
EndIf

Runtime Procedure MyResizeEvent()				; ----- resize callback-event
	CopyImage(#SourceImage, #DisplayImage)
	If IsGadget(#gad_Container)
		ResizeImage(#DisplayImage, GadgetWidth(#gad_Container), GadgetHeight(#gad_Container))
		SetGadgetState(#gad_Image, ImageID(#DisplayImage))
	EndIf
EndProcedure 

UseModule DynamicDialogs
UseModule DynamicDialogs_plain

ClearXML()

; ----- create the Dialog-Window

	Window(1, "", "Resize me ...", #PB_Window_SizeGadget | #PB_Window_SystemMenu, 450, 350)
		GridBox(5,0,0,#Expand_Yes, #Expand_Yes)
			Empty() : Empty() : Empty() : Empty() : Empty() : Empty()
			Container(#gad_Container,"",0,0,0,0,"",3,3) : EndContainer()
			Empty() : Empty() : Empty() : Empty() : Empty() : Empty()
		EndGridBox()
	EndWindow()

UnuseModule DynamicDialogs_plain	

Debug GetXML()

If OpenDialogWindow(0, GetXML(), 1)								; ----- Create and open the Dialog-Window
	
	UnuseModule DynamicDialogs	
	
	UseGadgetList(GadgetID(#gad_Container))					; ----- Insert ImageGadget into the Container
	ImageGadget(#gad_Image, 0,0,20,20,0)
	
	BindEvent(#PB_Event_SizeWindow, @MyResizeEvent())		; ----- Bind the Resize-Event to the Callback-Procedure
	MyResizeEvent()													; ----- need to call the Callback once, to do a first resize
	
	Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

[Kukulkan]

I would like to see a simple flag telling the image gadget in a dialogue to scale with it's content or not:

Code: Select all

<image name="imgBox1" scale=1 /> <!-- does resizing -->
<image name="imgBox2" scale=0 /> <!-- does no resizing -->

1 means resizing of both the dimensions of the gadget and also to scale the content (width, height, keep aspect ratio).

0 means both the gadget sizes and the image content should stay either the image size (lower priority) or given width and height values (higher priority).

[pwd]

Positive activity in Bugs section related to Dialog library brings me a hope to see suggestions about ToolBar, Menu, StatusBar and OpenGLGadget support will be implemented someday...

[Kukulkan]

So let's keep fingers crossed. A lot of good enhancements mentioned here in this thread!

[Andre]

Gadgets inside a ScrollAreaGadget should be able to resize automatically, when the window and therefore the container (the ScrollAreaGadget) resizes, at least for the width of the gadgets inside of the container.

Currently you can't even resize included gadgets inside a ScrollArea (e.g. like a listicon, which should get a greater width, when the window + container was resized to a larger size) manualy with ResizeGadget(). At least this should be possible to adapt the gadgets inside a ScrollArea manually after dialog resize.

Thank you!

[Andre]

from the DynamicDialogs thread:

..., like adding/removing gadgets during runtime...

But for the first Step it would be enough if hidden Gadgets will be counted with zero Size within the recalculation of RefreshDialog().
Should be easy to implement and provides a lot of opportunities.

[PureLust]

@Fred: Do you think you could throw an Eye (or an Egg) on the Dialog-Lib within the near future?

Thanks and !!!

[Andre]

Yes, the requested improvements to the Dialog lib would be very important for me too.
More than other 'new' gadget types etc. (which can be done or are already available as CanvasGadget solutions etc.)

Ok, no bumping anymore...