XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Grafische Primitive, XbaseParts und Darstellungsfragen allgemein.

Moderator: Moderatoren

Antworten
DelUser01

XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von DelUser01 »

Hallo

habe ein Problem und komme nicht dahinter.
Situation:
Alle benötigten Steuerfunktionen (PushButtons + MouseOver usw.) werden als Array erstellt.
Auf einem XbpCrt werden aus dem Array u.a. PushButtons erzeugt.
Alles funktioniert richtig.
An einer bestimmten Stelle werden alle Steuerfunktionen gelöscht, also auch die PushButtons.
Es läuft nun eine Funktion ab.
Danach werden alle Steuerfunktionen (u.a. die PushButtons) wieder aus dem Array erzeugt.
Die PushButtons werden auch angezeigt und man kann diese anklicken (aktiver Rahmen),
ABER aus AppEvent(...) kommt weder beim Anklicken noch beim drüberfahren ein Event zurück!!! MouseOver und anderes funktioniert.
Die PushButtons kann ich abfragen und die geben als Owner+Parent XbpCrt zurück. Müsste also auch OK sein.

Irgend etwas übersehe ich und finde es nicht heraus...

Noch ein Hinweis:
Am Anfang - wenn ich mit der Maus über den XbpCrt oder die PushButtons fahre - kommt der Event xbeM_Motion. Dann nach den erneuten Aufbau (wenn die PushButtons nicht reagieren) kommt beim Drüberfahren auch kein xbeM_Motion mehr...!?

Ergänzung 1:
Es sieht also so aus als würden bei der zweiten Erstellung nicht mehr auf dem XbpCrt sitzen und deshalb keinen Event erzeugen.

Hat jemand einen Tip?

Gruß
Roland
Zuletzt geändert von DelUser01 am So, 04. Jan 2015 23:53, insgesamt 1-mal geändert.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpPushButton() Problem im Hybrid-Modus

Beitrag von AUGE_OHR »

Roland Gentner hat geschrieben:Noch ein Hinweis:
Am Anfang - wenn ich mit der Maus über den XbpCrt oder die PushButtons fahre - kommt der Event xbeM_Motion.
Dann nach den erneuten Aufbau (wenn die PushButtons nicht reagieren) kommt beim Drüberfahren auch kein xbeM_Motion mehr...!?
Frage : kommt denn überhaupt noch ein xbeM_* Event ?

bei Hybrid-Modus frage ich lieber mal nach "wie" dein Code aussieht :
eigene AppSys() ?
mit /PM:PM ?
wer/was ist der Parent von den XbpPushButton() ?

im Hybrid-Modus mit XbParts muss man ja zwischen "Fenstern" wechseln.

Code: Alles auswählen

   SETAPPWINDOW( oCrt )
   oCrt:SetInputFocus := { | mp1, mp2, obj | SETAPPWINDOW( oCrt ), SETAPPFOCUS( oCrt ) }
   oCrt:setDisplayFocus := { | uNIL1, uNIL2, oSelf | SETAPPWINDOW( oCrt ), SETAPPFOCUS( oCrt )}
   SETMOUSE( .T. )
   oCrt:mouseMode := XBPCRT_MOUSEMODE_VIO
... und die Frage : warum "löscht" du die Buttons ?

den o:activate Codeblock Slot kannst du jederzeit neu belegen und mit o:setCaption() eine Caption neu bestimmen.
wenn du die nicht brauchst kannst du per o:Hide() den Button ausblenden und per o:Show() wieder anzeigen.
gruss by OHR
Jimmy
DelUser01

Re: XbpPushButton() Problem im Hybrid-Modus

Beitrag von DelUser01 »

Hallo Jimmy
kommt denn überhaupt noch ein xbeM_* Event ?
Nein - siehe oben Ergänzung 1
eigene AppSys() ?
Ja
mit /PM:PM ?
Ja
wer/was ist der Parent von den XbpPushButton() ?
beides XbpCrt
... und die Frage : warum "löscht" du die Buttons ?
es sind zu diesem Zeitpunkt mindestens drei Fenster geöffnet und jedes für sich selbstständig arbeitsfähig (Threads). Nun gibt es die eine oder andere Funktion welche mehrere der offenen Fenster beeinflusst. Und damit hier der User nichts tut was er in diesem Augenblick nicht tun sollte werden die PushButtons gelöscht (und ev. andere angezeigt). Im Augenblick mache ich das an der entsprechenden Stelle mit Hide und/oder XBP_DISP_APPMODAL.

Es sollte aber anders laufen und bin dabei auf das geschilderte Problem gestoßen.
DelUser01

Re: XbpPushButton() Problem im Hybrid-Modus

Beitrag von DelUser01 »

Ergänzung 2

Bin der Sache etwas weiter aber habe die Lösung noch nicht.
Die Frage die sich jetzt stellt ist:
Wo bzw. wie kann bei der Erstellung eines XbpPushButton angegeben werden in welchem AppEvent der entsprechende Button-Event auftauchen soll?

nochmal die Situation:
Thread 1 - XbpCrt mit AppEvent-Schleife 1
Thread 2 - XbpDialog mit AppEvent-Schleife 2

Die in Thread 1 erzeugten PushButtons werden in Thread 2 gelöscht und wieder erstellt.
Die PushButtons erscheinen auf dem XbpCrt, die Events der PushButtons kommen aber in der Event-Schleife 2 in Thread 2 heraus. Sollten aber in der EventSchleife 1 erscheinen.
DelUser01

Re: XbpPushButton() Problem im Hybrid-Modus

Beitrag von DelUser01 »

Ergänzung 3:

So wie ich mir das vorgestellt habe geht es nicht:
laut Xbase++-Doku sind die Object-Events an den Thread gebunden in dem diese erstellt wurden (s.u.).
Jetzt habe ich das per Umweg über "Benutzerdefinierte Ereigniscodes" erledigt.
Falls aber doch jemand eine gute Idee hat (noch gefällt mir das so nicht).
Multithreading
Alle aufgetretenen Ereignisse werden in eine Warteschlange (Event-Queue) gestellt und daraus von der Funktion AppEvent() wieder entnommen. Falls ein Programm in mehrere Threads aufgeteilt wird, ist zu beachten, daß eine Ereigniswarteschlange Thread-lokale Gültigkeit hat, d.h. jeder Thread hat eine eigene Event-Queue. Das bedeutet, daß jeder Thread, in dem Xbase Parts erzeugt worden sind, die Funktion AppEvent() aufrufen muß, damit Ereignisse für die in diesem Thread erzeugten Xbase Parts verarbeitet werden können.
...wieder etwas dazugelernt gelernt.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpPushButton() Problem im Hybrid-Modus

Beitrag von AUGE_OHR »

Roland Gentner hat geschrieben:Wo bzw. wie kann bei der Erstellung eines XbpPushButton angegeben werden in welchem AppEvent der entsprechende Button-Event auftauchen soll?
ein Windows Control schickt seine Event immer an den Parent (der es weiter an seinen Parent schicken kann wenn nicht "abgefangen" wurde).
Roland Gentner hat geschrieben: nochmal die Situation:
Thread 1 - XbpCrt mit AppEvent-Schleife 1
Thread 2 - XbpDialog mit AppEvent-Schleife 2

Die in Thread 1 erzeugten PushButtons werden in Thread 2 gelöscht und wieder erstellt.
Die PushButtons erscheinen auf dem XbpCrt, die Events der PushButtons kommen aber in der Event-Schleife 2 in Thread 2 heraus. Sollten aber in der EventSchleife 1 erscheinen.
hm ... in einem Thread was erzeugen und im anderen Thread löschen ... :shock:

mit einem XbpCrt anzufangen und den als Parent für XbParts zu nehmen halte ich für nicht geschickt.
ein XbpCrt ist ein XbPart und kein "Windows Fenster" ...

wenn du als Thread 1 mit einem XbpDialog anfangen würdest kannst du auf der o:DrawingArea als Thread 2 dein XbpCrt() laufen lassen.

Thread 3 , als MDI (?) XbpDialog, muss keine Eventschleife haben wenn als Parent oMain:DrawingArea verwendet wird.
wenn du aber AppDeskTop() als Parent angibst, was nicht MDI konform ist, benötigst du eine extra Eventschleife.

Wenn du das Main XbpDialog Object an den Thread 2 ( und weitere Threads ) übergibst und als Parent nutzt dann kommst du evtl. mit einer einzigen Eventloop aus.
gruss by OHR
Jimmy
DelUser01

Re: XbpPushButton() Problem im Hybrid-Modus

Beitrag von DelUser01 »

Hallo Jimmy
mit einem XbpCrt anzufangen und den als Parent für XbParts zu nehmen halte ich für nicht geschickt...
...nun, wenn Du mir das vor +/- 15 Jahren gesagt hättest wäre das vielleicht gegangen. Aber heute die Fenstertechnik ändern - vorerst unmöglich.

Es läuft ja soweit auch alles. Und hoffentlich führen auch weiterhin mehrere Wege nach Rom... :D
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: XbpPushButton() Problem im Hybrid-Modus

Beitrag von brandelh »

wie erzeugst du denn den Event ?
Bei PostAppEvent() kann man das Fenster / Control als Ziel angeben, mit mehreren GUI Threads habe ich zwar noch nicht gearbeitet,
aber wenn du ein Fensterobjekt übergibst, sollte das gehen.
Gruß
Hubert
DelUser01

Re: XbpPushButton() Problem im Hybrid-Modus

Beitrag von DelUser01 »

Hallo Hubert

genau - mit PostAppEvent( nMeinUserEvent , , , oXbpCrt ) geht das.
Habe ich schon öfter gemacht.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpPushButton() Problem im Hybrid-Modus

Beitrag von AUGE_OHR »

Roland Gentner hat geschrieben:...nun, wenn Du mir das vor +/- 15 Jahren gesagt hättest wäre das vielleicht gegangen.
Aber heute die Fenstertechnik ändern - vorerst unmöglich.
was ist da für ein Problem ?
eine "leere" Appsys und das was du in der AppSys hattest (oCrt) in die Main und dabei die o:DrawingArea als Parent angeben.
Roland Gentner hat geschrieben:Es läuft ja soweit auch alles. Und hoffentlich führen auch weiterhin mehrere Wege nach Rom... :D
wie schon gesagt ist ein oCrt "nur" ein XbPart als spezielles Xbase++ "Fenster" und nicht wie XbpDialog() ein "Windows Fenster" an das letztlich die Events der Childs gesendet werden.

... ich würde auch keine GUI Anwendung mit einem XbpStatic (statt XbpDialog) anfangen.
gruss by OHR
Jimmy
DelUser01

Re: XbpPushButton() Problem im Hybrid-Modus

Beitrag von DelUser01 »

Hallo Jimmy

sicher, vielleicht kein Problem,
aber da halte ich mich lieber an den Spruch "never change a running system"
Wie gesagt, es läuft alles. Warum soll ich mich da dann aus dem Fenster lehnen und irgendwas umstellen? Macht doch momentan gar keinen Sinn.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von brandelh »

du hast doch sicher ein XbpCrt je Thread oder ?
dann musst du den Event an das richtige Objekt senden.
Es kann natürlich sein, dass ich dich falsch verstanden habe.
Gruß
Hubert
DelUser01

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von DelUser01 »

Hallo Hubert

jedes "autonome" Fenster hat eine eigene Event-Schleife.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von AUGE_OHR »

Roland Gentner hat geschrieben:jedes "autonome" Fenster hat eine eigene Event-Schleife.
haben die Crt Fenster auch alle eine o:Titlebar := .T. ?

schalte doch mal die o:Titlebar auf .F. und du wirst "merken" wo die Events "hin gehen" ...
ein oCrt Object gibt es ja "so" gar nicht ... es ist nur ein "schwarzer Fleck" der KEINE Events verarbeiten kann.

Frage : wenn du Threads verwendest laufen die im Main Crt "Fenster" als MDI ?


das die o:Titlebar eine ( "Focus" ) Rolle spielt kannst du mit diesem MDI Demo ausprobieren.
Ich habe beim 2nd oCrt den o:Titlebar auf .F. gesetzt.

wenn du nun "in" das 1st oCrt klickst dann hast du den "Focus" ( SetAppFocus() ) auf dem oCrt aber nicht auf dem "Fenster" ( SetAppWindow() ) !
klicke wieder "in" das 2nd oCrt und dann auf die o:Titelbar des 1st oCrt und der "Focus" liegt auf dem "Fenster".
p.s. beim ersten Mal geht es noch, also mehrmals hin-und-her wechseln

wenn man "in" das 2nd oCrt klickt sieht man noch einen Effekt :

Code: Alles auswählen

oCrt:setDisplayFocus
wird ohne das "Fenster" nicht ausgeführt.

wenn nun das oCrt der Parent für deine XbParts ist nützt dir das nicht viel wenn der User "in" das oCrt klickt denn das "Fenster" muss nicht unbedingt auch den "Focus" haben.
Dateianhänge
XbpCrt.ZIP
(1.6 KiB) 177-mal heruntergeladen
gruss by OHR
Jimmy
DelUser01

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von DelUser01 »

Hallo Jimmy
haben die Crt Fenster auch alle eine o:Titlebar := .T. ?
Ja
Frage : wenn du Threads verwendest laufen die im Main Crt "Fenster" als MDI ?
Nein
wenn du nun "in" das 1st oCrt klickst...
wenn man "in" das 2nd oCrt klickt...
Nur das erste Fenster ist ein XbpCrt, die anderen sind XbpDialog.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: XbpPushButton() Problem im Hybrid-Modus

Beitrag von brandelh »

AUGE_OHR hat geschrieben: mit einem XbpCrt anzufangen und den als Parent für XbParts zu nehmen halte ich für nicht geschickt.
ein XbpCrt ist ein XbPart und kein "Windows Fenster" ...
das ist genau die Vorgehensweise, die viele Beispiele zeigen, auch wenn es nicht "schön aussieht".
Aber grundsätzlich ist (fast?) alles ein Windowsfenster, was auf einem Windowsrechner zu sehen oder nicht zu sehen ist !
Die Xbparts sind selbst von der Fensterbasisklasse abgeleitet (meist von XbpDialog) ...
Roland Gentner hat geschrieben:Die Frage die sich jetzt stellt ist:
Wo bzw. wie kann bei der Erstellung eines XbpPushButton angegeben werden in welchem AppEvent der entsprechende Button-Event auftauchen soll?
Gar nicht ! Ein Control verarbeitet Events ! PostAppEvent() sendet welche und über den letzte Parameter kann man das gewünschte Ziel angeben.
Roland Gentner hat geschrieben: nochmal die Situation:
Thread 1 - XbpCrt mit AppEvent-Schleife 1
Thread 2 - XbpDialog mit AppEvent-Schleife 2

Die in Thread 1 erzeugten PushButtons werden in Thread 2 gelöscht und wieder erstellt.
Die PushButtons erscheinen auf dem XbpCrt, die Events der PushButtons kommen aber in der Event-Schleife 2 in Thread 2 heraus. Sollten aber in der EventSchleife 1 erscheinen.
Thread 2 darf keine Controls von Thread 1 löschen !
Bei der neu Anlage werden diese wohl zu Thread 2 zugeordnet.

Du kannst entweder in Thread 2 einen User Event erzeugen, der in Thread 1 die PushButtons wie gewünscht ändert,
oder aber du versteckst nur die unnötigen PushButtons und zeigst die geänderten wieder an. So müsste die Zuordnung zu Thread 1 erhalten bleiben.

Eventuell kannst du auch mit dem Setzen des Focus den Empfänger bestimmen ... aber wie geschrieben habe ich sowas noch nie gemacht.
In Beispielen mit mehreren XbpCrt() wird jeweils SetAppWindow(oNunAktivesCrtFenster) verwendet um das Hauptfenster festzulegen, eventuell ist da auch eine Lösung möglich.
Gruß
Hubert
DelUser01

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von DelUser01 »

Hallo Hubert
Thread 2 darf keine Controls von Thread 1 löschen !
was heißt da 'darf nicht', es geht aber, deshalb bin ich davon ausgegangen dass es auch geht wenn Controls angelegt werden (warum auch nicht...)
Eventuell kannst du auch mit dem Setzen des Focus den Empfänger bestimmen
hatte ich auch schon probiert, geht aber nicht
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von brandelh »

Roland Gentner hat geschrieben:Hallo Hubert
Thread 2 darf keine Controls von Thread 1 löschen !
was heißt da 'darf nicht', es geht aber, deshalb bin ich davon ausgegangen dass es auch geht wenn Controls angelegt werden (warum auch nicht...)
nun weil eigentlich die Threads verschiedene XbpCrt() Fenster gegenseitig voreinander schützen sollen, so habe ich das verstanden (aber selbst nie gemacht).

Hast du probiert die Buttons nur zu verstecken, umzubenennen und notfalls zu verschieben ?
Solange das alte Objekt bestehen bleibt, sollte es auch den Thread nicht wechseln.
Gruß
Hubert
DelUser01

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von DelUser01 »

Hallo Hubert
brandelh hat geschrieben:Hast du probiert die Buttons nur zu verstecken, umzubenennen und notfalls zu verschieben?
Alles kein Problem...

War mir eben nur nicht klar dass Event-Objekte nicht aus verschiedenen Threads direkt in unterschiedliche Event-Queues eingereiht werden können.

Wie schon am Anfang erklärt geht es mir darum, dass ich die Buttons (und anderes) meiner Hauptsteuerung (das 1. XbpCrt-Fenster) von anderen Fenstern aus beeinflussen kann.
Mit meiner ursprünglichen Vorgehensweise geht das halt jetzt nicht und ich mache es anders.
Also mache dir keine weiteren Gedanken...
(vielleicht geht das ja Mal in v2.x oder später. sollte ja innerhalb Xbase++ kein Problem sein)
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von Martin Altmann »

Moin Roland,
das wird auch in zukünftigen Xbase++-Versionen nicht anders sein und wäre auch Blödsinn (sorry, aber manchmal muss es einfach raus) :!:
Ein Thread() wird immer die Kontrolle über die Objekte haben, die er erstellt!
Mach' es so, wie Hubert es bereits vorgeschlagen hat und Du wirst keinerlei Probleme mehr haben:
Wenn Thread2 feststellt, dass die XbpPushButton()s in Thread1 geändert werden müssen, sendet Thread2 einfach einen entsprechend von Dir definierten Userdefined-Event (xbeP_User + nI) an Thread1! In Thread1 reagierst Du auf genau diesen Event entsprechend: Lösche die betreffenden Objekte und erstelle an ihrer Stelle die anderen neu!
Manchmal kann das Leben so einfach sein - und so funktioniert nun mal ein Event-getriggertes Betriebssystem.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von Herbert »

Hmm, da komme ich als Threadanhäufungsgegner wieder ins "dreinreden".
Threads haben die Aufgabe, unabhängig von andern Threads eine Aufgabe zu lösen. In diesem Fall liegt ein Designfehler vor und es dürften meiner meinung nach für solche Aufgaben keine neue Threads erstellt werden.
Warum? Weil Interaktionen zwischen Threads sehr viel bewirken. Synchronisation ist gefragt. Wer weiss denn, wo Thread 1 gerade steckt und was der alles momentan von sich aus verändert? Und nun kommt der eigentlich unabhängige Thread 2 und verändert in Thread 1 einfach mal etwas. Das kann zu weiteren unerwünschten Effekten führen.
Daher sollten solche einfach sich ansehende Interaktionen möglichst vermieden werden. Windows 7 und 8 kann sehr wohl viel auch selber in den Kernels aufteilen. Ich zweifle, ob in solchen Fällen die Threaderstellung einen Geschwindigkeitsgewinn bringt.
Grüsse Herbert
Immer in Bewegung...
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von brandelh »

Zu den Threads gibt es ein schönes Beispiel, das die gegenseitige Benachrichtigung zeigt:

...\XPPW32\source\samples\basics\THREAD\Coffee.prg

ansonsten kann ich Heribert nur Recht geben, ich nutzte für das eigentliche GUI Programm (und in älteren XbpCrt() )
immer nur einen Thread für die Anzeige und den normalen Programmablauf.
Das vereinfacht das normale Leben enorm ;-)

Wenn ich dann z.B. eine längere unabhängige Auswertung fahre oder z.B. auch Seitenlange Reports erstelle,
dann lagere ich bei Bedarf diese Aufgabe in Threads aus, wobei das durch die Druckunterstützung von Windows kaum noch nötig ist.
Gruß
Hubert
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von Martin Altmann »

Herbert und Hubert,
klar habt ihr Recht - aber meine Antwort bezog sich auf Rolands Anforderung, in einem Thread die Objekte zu ändern - wobei die Feststellung, dass dies getan werden muß, nur in einem anderen Thread erfolgt! So ist seine Konstellation. Und dieses "Dilemma" kann man nur sinnvoll so umsetzen, wie Hubert das ursprünglich vorschlug! Der Thread, der seine Objekte unter seiner eigenen Verwaltung hat, muss auch für das Löschen und Neuanlegen sorgen! Der andere Thread darf ihn im Prinzip nur darüber informieren, dass es jetzt an der Zeit ist :!:
Wenn der andere Thread die Aufgabe komplett selber übernimmt, dann "gehören" die neuen Objekte auch ihm - und das ist ja nicht gewollt.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von brandelh »

Martin Altmann hat geschrieben:Herbert und Hubert,
klar habt ihr Recht - aber meine Antwort bezog sich auf Rolands Anforderung,
ich wollte dir nicht widersprechen ! :wink:
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpPushButton() Problem im Hybrid-Modus [ERLEDIGT]

Beitrag von AUGE_OHR »

Nur das erste Fenster ist ein XbpCrt, die anderen sind XbpDialog.
zeige doch mal wie du aus dem XbpCrt zum XbpDialog (im Thread ?) kommst und was der Parent / Owner ist.
War mir eben nur nicht klar dass Event-Objekte nicht aus verschiedenen Threads direkt in unterschiedliche Event-Queues eingereiht werden können.
also das ist "so" nicht richtig:
ein XbPart sendet seine Events an seinen Parent (und der ggf. zu seinem Parent) ... egal aus welchem Thread wenn der Parent übergeben wurde !
ABER : man kann ja einen Event "abfangen" in einem Thread ... dann wird er ja aus der Queue genommen und kommt nicht beim Parent an.

auch bedeutet ein "aktives" Child "Fenster", was im Vordergrund im Thread läuft, nicht das in "der" Event Scheife etwas "abgearbeitet" wird ...
man kann mit AppEvent() einen Event aus der Queue entnehmen und "verarbeiten" oder er wird durch o:handleEvent() weiter geleitet ( an den Parent )

und am Ende sind wir wieder beim "Root" CRT ... mit SetAppWindow() was das "Fenster" ist.
dieses stellt nun "zusätzliches" Problem da weil eine ? / ?? / SAY "Ausgabe" nur erfolgen darf wenn es = SetAppWindow() ist.
ein Tastendruck, der nicht abgefangen wird, ob Thread oder nicht kann bis in die "Main" Event-Loop gelangen ... wo es alles mögliche auslösen "könnte".




Ich habe, für CRT "Fenster", statt GUI Buttons einfach mit oCrt:lbDown ... meine F-Keys haben unter Cl*pper ja schon ihren "Platz"
anbei Demo mit oCrt:lbDown -> F12 -> GUI Dialog
FKEYS.ZIP
(7.53 KiB) 148-mal heruntergeladen
btw. bei ausprobieren des Demo hatte ich STATIC oThread nicht richtig "entsorgt" -> ging nur 1 x ...
also mal überprüfen "ob" der Thread überhaupt richtig von oButton:activate richtig aufgerufen wird.

wenn man nun, mit klick auf F12, im GUI Dialog ist solltest du jetzt mal eine Taste*** drücken ;)
wenn du nun den GUI Dialog verlässt (F12) dann wirst du im oCrt "Fenster" eine Meldung sehen die aus dem GUI Thread kommt ...

***ich habe nur die Events < xbeB_Event genommen
gruss by OHR
Jimmy
Antworten