Parent disablen -> Child enabled?!

[Markus Walter]

Hi,

entweder stehe ich jetzt fürchterlich auf dem Schlauch, oder...

Ich habe ein DCSTATIC als Groupbox. Auf diesem sind mehrere DCGET plaziert. Ich bin davon ausgegangen, dass die DCGETs disabled werden, wenn ich die Groupbox über die WHEN-Klausel disable... Das ist aber nicht so. Auch ein dc_getrefresh hilft nicht...

Mache ich da einen Denkfehler, stehe ich auf dem Schlauch, oder...

Code: Alles auswählen

#include "dcdialog.ch"
#include "appevent.ch"

function Appsys()
return NIL

procedure main()
local getlist := {}, getoptions := {}, lRet, oStatic, cVar1 := space(10), cVar2 := space(10), cVar3 := space(10), lAktiv := .t.

  @ 3,3 DCSTATIC TYPE XBPSTATIC_TYPE_GROUPBOX SIZE 20, 4 OBJECT oStatic WHEN {|| lAktiv}
  @ 1, 1 DCGET cVar1 PARENT oStatic                           // dieses get ist immer enabled
  @ 2, 1 DCGET cVar2 PARENT oStatic WHEN {|| lAktiv}   // so geht es

  @ 9, 3 DCGET cVar3

  @ 10, 3 DCPUSHBUTTON SIZE 10, 2 CAPTION "um" ACTION {|| if(lAktiv, lAktiv := .f., lAktiv := .t.), dc_getrefresh() }

  DCGETOPTIONS TITLE "Test"

  DCREAD GUI TO lRet OPTIONS getoptions FIT

RETURN

Weiß jemand Rat?

[Tom]

Hallo, Markus.

Wie Du in _DCGETBX.PRG sehen kannst (irgendwo ab Zeile 5600, je nach Version), geht die entsprechende Funktion (DC_GetWhen) nicht den jeweiligen ChildList-Baum durch. Die meisten Parts (Menüs, Browses usw.) disablen ihre "Kinder" (Submenus, Browse-Columns) automatisch (also implizit), wohingegen Statics, die andere Elemente enthalten, dies nicht tun. Und Roger macht es auch nicht. Du musst also die WHEN-Klausel an jedem Element wiederholen. Einfacher ist das mit HIDE, weil natürlich auch die Elemente verschwinden, wenn deren Parent nicht mehr angezeigt wird.

[Markus Walter]

Hi Tom,

hm, wäre schön, wenn das automatisch ginge... So kenne ich das von anderen Entwicklungssystemen.

Naja, ich frage mal bei Roger. Bei komplexen Masken wäre das schon eine Hilfe.

Hattest Du mal Zeit nach dem Verhalten beim Klicken in DCGETs zu schauen (im build 253)?

[Tom]

Hallo, Markus.

Welches Verhalten der DCGETs denn nun noch? Bei mir funzt alles einwandfrei.

[Wolfgang Ciriack]

Hallo Markus,
bei DCMULTILINE klappt es, beim Mausklick bleibt der Cursor da, wo du hingeklickt hast.
Bei DCGET geht der erste Klick an den Anfang, danach, wenn der Focus auf dem DCGET ist, bleibt der Cursor an der Stelle.
Ich glaube, dass war nicht, was du hören wolltest.

[Markus Walter]

Hallo Tom,
hallo Wolfgang,

ich hatte doch diese Woche in Rogers Board 2 "Anomalien" (Windows untypisch) gepostet:

1. ein Get mit einigen Leerzeichen hinter einem Wort. Wenn man nun in den Bereich der Leerzeichen klickt, sollte der Cursor direkt hinter dem letzten wirklichen Buchstaben stehen und nicht dort wohin man geklickt hat.

2. Wenn man dorthin klickt, wo Buchstaben sind, sollte der Mauszeiger auch dort stehen. Auch wenn man von einem anderen Steuerelement kommt. Da steht der Cursor meist ganz am Anfang oder der Text bis zur Mausposition ist markiert.

@Tom: Diese Punkte hattest Du selbst mal bei Roger reklamiert (April 09).

Ich setze noch build 252 ein und wollte wissen, ob das in einem neueren build (253 oder 254) gefixt/geändert ist. Den ersten Punkt hatte/habe ich selbst gelöst, aber den zweiten habe ich nach wie vor.

[Ewald]

Hallo Marcus,
ich glaube, ich hatte da schon mal das gleiche Problem.
Lt. Beschreibung soll es genau so funktionieren. Tut es aber bei mir auch nicht.
http://www.xbaseforum.de/viewtopic.php? ... &sk=t&sd=a
Ich habe dann auch das valid an die einzelnen gets gehangen.
Schade eingentlich
Gruß
Ewald

[Tom]

Das Verhalten wird im nächsten eXpress++-Build (255) korrigiert sein.

[Markus Walter]

Hi Tom,

danke, ich weiß. Roger hatte mir vorab die Änderung per mail geschickt und er veröffentlicht ja jetzt auch die changes in seinem Forum - finde ich eine gute Idee von mir