DialogDesign0R V1.85

[Omi]

Hallo HeXOR,

leider stellen sich noch einige kleine Probleme beim Testen Deines DialogDesigners heraus, insbes. auf gtk3 (ein Teil der Probleme wie D&D liegen allerdings auch an meinem Hauptlinux).
Bin allerdings ebenfalls noch eine xml-Dialog-#Null.
Trotz allem Top Arbeit bisher

Ich habe festgestellt, dass die Funktion gtk_tree_view_column_cell_get_size_() immer von der obersten (sichtbaren) Zeile zählt ...

Es gibt API-Funktionen, die hier Koordinaten-Umrechnungen für das TreeView vornehmen wie:
gtk_tree_view_convert_tree_to_widget_coords(*tree_view.GtkTreeView, bx.I, by.I, *wx, *wy)
gtk_tree_view_convert_tree_to_bin_window_coords(*tree_view.GtkTreeView, bx.I, by.I, *wx, *wy)
gtk_tree_view_convert_widget_to_bin_window_coords(*tree_view.GtkTreeView, bx.I, by.I, *wx, *wy)
gtk_tree_view_convert_bin_window_to_tree_coords(*tree_view.GtkTreeView, bx.I, by.I, *wx, *wy)
gtk_tree_view_convert_bin_window_to_widget_coords(*tree_view.GtkTreeView, bx.I, by.I, *wx, *wy)

Da ich's leider (noch) nicht richtig testen kann, weiß ich auswendig nicht die für Deine Zwecke passende Funktion, tippe momentan aber auf gtk_tree_view_convert_bin_window_to_tree_coords()
Diese müßte die Strecke bis zum Beginn des Scrollable (ohne Headerzeile) aus einer y-Koordinate von by.i nach *wy zurückgeben, also für by= 0 (Sliderabhängig sichtbares ganz oben) zu Slider-0-Pos, ganz oben)

Vielleicht hilfts Dir weiter (und ich leg Dir mit meiner Rumraterei nicht noch ein zusätzliches Ei)

Gruß, Charly

[HeX0R]

Der Tipp scheint nicht schlecht, habe das mal eben eingebaut, bei mir zumindest funktioniert das jetzt so wie es soll, bitte testen.

Was mich aber wirklich ärgert, in der Hilfe steht bem DropCallback():

Durch die Rückgabe von #True erlaubt der Callback, dass die Aktion an diesem Punkt stattfindet. Durch die Rückgabe von #False unterbindet der Callback die Aktion (der Mauscursor wird durch die "Drag"-Quelle in einen "Verboten"-Cursor geändert).

Das geht bei mir unter Linux nicht, nur unter Windows!
Funktioniert das bei irgendwem?

Das war der Hauptgrund, wieso ich das so umständlich gemacht habe, ich wollte, dass der Benutzer während des draggens gleich sieht, wo er droppen kann, und wo nicht.

[Edit]
Ich habe jetzt mal die Zelle in Linux markiert (wirkt jetzt ähnlich wie in Windows), auf die gedroppt werden würde, man sieht schon, dass es nicht ganz rund läuft, aber ehrlich?
Ist mir zuviel Gefrickel mit diesem GTK-Kack, wenn's von euch einer hinbekommt, dann immer her damit, ich mach an dieser Krücke jetzt erst mal nix mehr!

[HeX0R]

Das D&D liegt erst mal auf Eis, habe aber wenigstens den Tipp von Bisonte umgesetzt, bei diesen FatCow Icons hat man ja echt eine irre große Auswahl!
Also jetzt mit Icons.

[Kiffi]

Also jetzt mit Icons.

très chic!

Mir ist noch folgendes aufgefallen (unter Windows):

Punkt 1:

* DialogDesign0R gestartet
* window hinzugefügt
* vbox hinzugefügt
* button hinzugefügt

Das Preview-Fenster zeigt den Button allerdings nicht an. Erst wenn ich beispielsweise die Text-Eigenschaft des Buttons ändere, wird das Preview-Fenster korrekt aktualisiert.

Punkt 2:

* DialogDesign0R gestartet
* window_1 hinzugefügt
* window_2 hinzugefügt
* window_3 hinzugefügt
* nun Rechtsklick auf window_1 und Delete ausgewählt

-> Error in Zeile 207: [ERROR] GetXMLNodeName(): This type of XML node does not have a name.

Code: Alles auswählen

If LCase(GetXMLNodeName(*Node)) = "window"

Punkt 3:

Ich habe ein etwas umfangreicheres XML (21 Windows) per Hand gebaut und wollte es in den DialogDesign0R laden. Nach dem Laden steht im Log-Fenster, dass das XML erfolgreich geladen wurde. Im Tree ist die Windows-Struktur allerdings nicht zu sehen. Bei Interesse kann ich Dir das XML mal per PM zukommen lassen.

// Edit: Scheint so, als ob der DialogDesign0R keine Kommentare (<!-- comment -->) im XML mag. Wenn ich diese entferne, dann wird die Tree-Struktur angezeigt.

Danke & Grüße ... Peter

[HeX0R]

Na das ist doch mal ein brauchbarer Fehlerbericht.
Vielen Dank, schaue mir das die Tage an!

[Edit]
Alle drei gefixt, kann das aber erst heute Abend hochladen.
Eine Fage:
Kommentare werden trotzdem noch ignoriert, sie bleiben zwar in der XML, aber Du siehst sie nicht im Design0R.
Brauchst Du da die Möglichkeit die zu editieren, oder auch nur anzuschauen?

[HeX0R]

So, habe das mal neu hochgeladen, das ScintillaGadget hatte auch noch gefehlt.
Ausserdem habe ich die D&D Linuxvariante von Omi eingebaut (Danke nochmal!), bitte mal testen.

Was die Kommentare betrifft:
Ich denke es hätte schon seinen Charme, wenn man die auch in der Baumstruktur sehen könnte und auch ändern/hinzufügen/löschen.
Das wird aber etwas aufwändiger, weil sich Kommentare doch schon ziemlich anders verhalten, da ist genug Platz für mögliche Bugs...

Ich setze es mal auf die (imaginäre) ToDo-Liste mit niedriger Priorität.

Ach ja, an die Windows-API-Gurus:
Wie kann ich denn aus einem TreeItemHandle den Index ermitteln?
Im Moment habe ich da eine ziemliche Krücke hektisch zusammengebastelt:

Code: Alles auswählen

Protected TreeItemHandle
TreeItemHandle = SendMessage_(GadgetID(DID("tree_objects")), #TVM_GETNEXTITEM, #TVGN_FIRSTVISIBLE, #Null)
For i = 0 To CountGadgetItems(DID("tree_objects")) - 1
	If GadgetItemID(DID("tree_objects"), i) = TreeItemHandle
		Break
	EndIf
Next i 

[RSBasic]

Ach ja, an die Windows-API-Gurus:
Wie kann ich denn aus einem TreeItemHandle den Index ermitteln?

Aber gerne doch:

Code: Alles auswählen

EnableExplicit

Define a
Define TVITEM.TVITEM

If OpenWindow(0, 0, 0, 500, 400, "Window", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  TreeGadget(1, 10, 10, 480, 100)
  For a = 0 To 20
    AddGadgetItem (1, -1, "Item " + Str(a), 0, 0)
  Next
  
  Repeat
    Select WaitWindowEvent()
      Case #PB_Event_Gadget
        Select EventGadget()
          Case 1
            TVITEM\mask = #TVIF_PARAM
            TVITEM\hItem = SendMessage_(GadgetID(1), #TVM_GETNEXTITEM, #TVGN_FIRSTVISIBLE, 0)
            If TVITEM\hItem
              SendMessage_(GadgetID(1), #TVM_GETITEM, 0, TVITEM)
              Debug TVITEM\lParam
            EndIf
        EndSelect
      Case #PB_Event_CloseWindow
        End
    EndSelect
  ForEver
EndIf

[Kiffi]

So, habe das mal neu hochgeladen

super, danke!

Ausserdem habe ich die D&D Linuxvariante von Omi eingebaut (Danke nochmal!), bitte mal testen.

prima! Funktioniert unter Linux problemlos (besser als die Variante zuvor).

Was die Kommentare betrifft: [...]

die Kommentare hatte ich nur verwendet, weil ich das XML per Hand erstellt habe. Ist für mich eigentlich nicht wirklich wichtig.

Bei folgendem XML macht der Design0R allerdings noch die Grätsche:

Code: Alles auswählen

<dialogs>

	<!-- Kommentar1 -->

	<window id="#id1" name="name1" text="" minwidth="410" minheight="295" flags="#PB_Window_ScreenCentered | #PB_Window_BorderLess">
	</window>
	
	<!-- Kommentar2 -->

	<window id="#id2" name="name2" text="" minwidth="500" minheight="400" flags="#PB_Window_ScreenCentered | #PB_Window_BorderLess">
	</window>		
	
</dialogs>

Zeile 846: Name = GetXMLNodeName(*node)
[09:08:54] [ERROR] GetXMLNodeName(): This type of XML node does not have a name.

Einen Bug hätte ich noch:

Ich verwende in meinem XML 'eigene' Attribute. Beispielsweise sowas hier (für SpiderBasic):

Code: Alles auswählen

<button id="#cmdOK" style="font-family:Verdana;font-size:24px" />

(In meinem Code überschreibe ich OpenXMLDialog() mit einem Macro und kann dann das style-Attribut dort auswerten.)

Wenn solche benutzerdefinierten Attribute im XML vorhanden sind und ich das entsprechende Gadget mit der Maus im Tree anklicke, dann gibt's einen Fehler:

[09:16:34] [ERROR] The specified #Gadget is not initialised.
Zeile 813: SetGadgetText(DID(a$), b$)

Hier das entsprechende XML:

Code: Alles auswählen

<dialogs>
	<window id="#id1" name="name1" text="" minwidth="410" minheight="295" flags="#PB_Window_ScreenCentered | #PB_Window_BorderLess">
		<button id="#cmdOK" style="font-family:Verdana;font-size:24px" />
	</window>
</dialogs>

Danke im Voraus & Grüße ... Peter

[Shardik]

Aber gerne doch:

Leider funktioniert Dein Beispiel nicht so, wie ich mir das vorgestellt habe. Es zeigt immer den Index 0 an solange der sichtbare Bereich nicht verschoben wird. Wird der Scrollbalken verwendet und ein Eintrag aus dem vorher nicht sichtbaren Bereich angeklickt, z.B. "6", dann ändert sich der angezeigte Index von 0 auf 1.

Ich habe daher einmal ein eigenes Beispiel erstellt, das für alle Einträge das ItemHandle ermittelt und aus dem ItemHandle den Index. Und auch für gerade nicht sichtbare Einträge wird der korrekte Index ermittelt:

Code: Alles auswählen

EnableExplicit

Define i.I
Define ItemHandle.I

Procedure.I GetIndexFromItemHandle(TreeGadgetID.I, ItemHandle.I)
  Protected Item.TVITEM

  Item\mask = #TVIF_PARAM
  Item\hItem = ItemHandle
  SendMessage_(GadgetID(TreeGadgetID), #TVM_GETITEM, 0, @Item)

  ProcedureReturn Item\lParam
EndProcedure

OpenWindow(0, 100, 100, 390, 70, "TreeGadget-Demo")
TreeGadget(0, 5, 5, WindowWidth(0) - 10, WindowHeight(0) - 10)
AddGadgetItem(0, -1, "Item 1", 0, 0)
AddGadgetItem(0, -1, "Subitem 1", 0, 1)
AddGadgetItem(0, -1, "Subitem 2", 0, 1)
AddGadgetItem(0, -1, "Subitem 3", 0, 1)
AddGadgetItem(0, -1, "Subitem 4", 0, 1)
SetGadgetItemState(0, 0, #PB_Tree_Expanded)

For i = 0 To CountGadgetItems(0) - 1
  ItemHandle = GadgetItemID(0, i)
  Debug Str(ItemHandle) + " -> " + GetIndexFromItemHandle(0, ItemHandle)
Next i

Repeat
Until WaitWindowEvent() = #PB_Event_CloseWindow

[oO0XX0Oo]

Hi,

Ich hab mal probehalber die hier gepostete dd.xml Datei genommen und das folgende GIF aufgenommen:



Ich ziehe hier mit der Maus am Splitter und wie man sieht, ist das "tearing" dabei nicht zu
übersehen. Auffällig ist auch die Veränderung der Drop-Down-Box unterhalb von
"OnXXX Procedures".

Ist das ein bug oder ein generelles Verhalten von XML Dialogen?