XbpBrowse:stableBlock

Grafische Primitive, XbaseParts und Darstellungsfragen allgemein.

Moderator: Moderatoren

Antworten
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

XbpBrowse:stableBlock

Beitrag von Jan »

Moin,

der :stableBlock ist ja ein Codeblock. Leider hat Alaska die Doku dazu extremst runter gefahren, ich finde da jedenfalls rein überhaupt gar nichts zu. Weiß jemand, was die Parameter sind, die automatisch generiert werden in [|Parameter| .....}?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: XbpBrowse:stableBlock

Beitrag von Tom »

Im XbpBrowse-Quellcode allerdings für die 1.9SL1 steht das hier für die Auswertung des StableBlocks (in der Methode ForceStable):

Code: Alles auswählen

IF ValType( ::StableBlock ) == "B"
  EVAL ( ::StableBlock, self:&(self:className()) )
ENDIF
Der (einzige) Parameter ist also der Name der Klasse, wenn ich das richtig verstehe.

Edit: Quatsch, da ist ja ein Makrooperator davor. Also das Klassenobjekt.
Herzlich,
Tom
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: XbpBrowse:stableBlock

Beitrag von Jan »

Hallo Tom,

danke für die Bestätigung. Ich hatte mir sowas ähnliches fast gedacht. War aber eher von der sonst üblichen Parameterzahl drei ausgegangen. Wo dann meist der Dritte das self ist. Und die davor dann entweder uNil, oder was reales.

Warum Alaska da nicht mal eine ordentliche Doku zu macht für all die Methoden, die es da gibt. Vor Allem, wenn die auch mal mit der Anzahl der Parameter spielen.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: XbpBrowse:stableBlock

Beitrag von Tom »

Ja, das stimmt. Ich hänge dann immer eine Anzahl Parameter rein und schaue sie mir einfach an:

Code: Alles auswählen

{|a,b,c,d,e,f|MsgBox(Var2Char(a)+"|"+Var2Char(b) ...)}
Bei StableBlock hatte ich ja den Quellcode, das war einfacher.
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: XbpBrowse:stableBlock

Beitrag von brandelh »

Jan hat geschrieben: Mi, 06. Dez 2017 10:35 War aber eher von der sonst üblichen Parameterzahl drei ausgegangen.
Wo dann meist der Dritte das self ist. Und die davor dann entweder uNil, oder was reales.
natürlich wäre eine bessere Doku nützlich, aber die "üblichen 3 Parameter" für alle Methoden / Funktionen / Codeblocks gibt es so nicht !

Wenn in der Hilfe ein "callback" Codeblock beschrieben wird, gilt die 3 Parameter Regel, denn ein codeblock, der von einem Control "angerufen wird" (= "callback"), benötigt die Infos (P1,P2,oWerRuftMichAn) ...
Für normale Funktionen und codeblöcke ist Anzahl und Bedeutung der Parameter beliebig - von Alaska oder dem Autor vorgegeben.
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: XbpBrowse:stableBlock

Beitrag von Jan »

Hallo Hubert,

ich stimme Dir in sofern zu, als das prinzipiell selbstverständlich die Anzahl der Parameter egal ist und sehr unterschiedlich sein kann. Aber die Erfahrung zeigt, das zumindest in den XbParts von Alaska es fast durchgängig drei sind. Wenn dann mal einer nicht belegt ist, dann ist der halt uNil. Wie z. B. bei XbpBrowse:keyboard. Da ist das dann halt {|nKeyboard, uNil, self| ...}.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: XbpBrowse:stableBlock

Beitrag von Jan »

Hallo Tom,

ja, so hatte ich mir auch schon teilweise was zusammengeraten. Es lebe der kriminalistische Spürsinn ..

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

Re: XbpBrowse:stableBlock

Beitrag von brandelh »

Jan hat geschrieben: Mi, 06. Dez 2017 11:34 ich stimme Dir in sofern zu, ... Aber die Erfahrung zeigt, das zumindest in den XbParts von Alaska es fast durchgängig drei sind.
Wenn dann mal einer nicht belegt ist, dann ist der halt uNil. Wie z. B. bei XbpBrowse:keyboard. Da ist das dann halt {|nKeyboard, uNil, self| ...}.
Nochmal, aber nur wenn es CALLBACK Codeblöcke sind ;-)

Man könnte z.B. in diesen ein Tone() hinterlegen, damit der Anwender aufwacht sobald die Daten eingelesen und komplett angezeigt werden. Sind ja nicht die schnellsten die XbpBrose() :badgrin:
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: XbpBrowse:stableBlock

Beitrag von AUGE_OHR »

die 3 Parameter lauten unter Xbase++ :

Code: Alles auswählen

mp1,mp2,oXbp 
und sind überall dort vorhanden wo ein Windows Event auf ein Callback Slot geleitet wird.

---

was o:Stableblock angeht : wie auch in einer Event Schleife sollte "wenig" Code, der Zeit braucht, ausgeführt werden.
man darf aber "AUF KEINEN FALL" dann noch den Pointer (= RECNO() ) verändern denn dann ist er eben "nicht stable"

was man aber machen kann ist, per Event, einen anderen Thread damit anzusteuern der z.b. die RELATION anzeigt

Code: Alles auswählen

o:StableBlock := { || PostAppEvent( MyEvent, FIELD->RECNO(),, oThread2 ) }
gruss by OHR
Jimmy
Antworten