XbpPresSpace und GRAxxx [erledigt]

Grafische Primitive, XbaseParts und Darstellungsfragen allgemein.

Moderator: Moderatoren

Benutzeravatar
Wolfgang_B
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 484
Registriert: Do, 14. Jun 2007 18:22
Wohnort: 94065 Waldkirchen
Hat sich bedankt: 14 Mal
Danksagung erhalten: 5 Mal

XbpPresSpace und GRAxxx [erledigt]

Beitrag von Wolfgang_B »

Hallo,
ich versuche gerade eine Linie in ein oDlg-Objekt zu zeichnen. Es gelingt mir aber nicht.

Code: Alles auswählen

 oPS := XbpPresSpace():new( drawingArea , , {10,100}, {200,450} ) 
   oPS:create()
   IF GraLine( oPS, {10,50}, {100,200} )
 		MSgBox("Erfolg")
 	ELSE
 		MsgBox("kein Erfolg")
 	ENDIF	
Er sagt mir "Erfolg", ich sehe aber nichts - warum?
Zuletzt geändert von Wolfgang_B am Di, 17. Jul 2018 17:49, insgesamt 2-mal geändert.
Beste Grüße
Wolfgang

Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
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: XbpPresSpace und GRAxxx

Beitrag von brandelh »

Lies dir einmal ":lockPS() --> oPresSpace" durch und versuche es so:

Code: Alles auswählen

oPS := drawingArea:lockPS()
Gruß
Hubert
Benutzeravatar
Wolfgang_B
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 484
Registriert: Do, 14. Jun 2007 18:22
Wohnort: 94065 Waldkirchen
Hat sich bedankt: 14 Mal
Danksagung erhalten: 5 Mal

Re: XbpPresSpace und GRAxxx

Beitrag von Wolfgang_B »

Hallo Hubert,
funktioniert nicht .

Code: Alles auswählen

oPS := XbpPresSpace():new( drawingArea , , {10,100}, {200,450} )
 oPS := drawingArea:lockPS()

 IF GraLine( oPS, {10,50}, {100,200} )
 		MSgBox("Erfolg")
 ELSE
 		MsgBox("kein Erfolg")
 ENDIF	
   
 oPS:unlockPS()
ohne "unlockPS()" tut sich nichts, außer daß ich die "EXE" nicht mehr beenden kann. Mit "unlockPS()" heißt es, "Methode ist für dieses Objekt unbekannt -> unlockPS()"
Beste Grüße
Wolfgang

Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: XbpPresSpace und GRAxxx

Beitrag von ramses »

Hallo Wolfgang

hast du die Linienattribute (Farben/Linientyp usw.) mit graSetAttrLine() vor dem Zeichnen mit graline() gesetzt?

Gruss Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
Wolfgang_B
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 484
Registriert: Do, 14. Jun 2007 18:22
Wohnort: 94065 Waldkirchen
Hat sich bedankt: 14 Mal
Danksagung erhalten: 5 Mal

Re: XbpPresSpace und GRAxxx

Beitrag von Wolfgang_B »

Hi Carlo,
ich gebs erstmal auf.

Wenn ja mal wenigstens ein Beispiel aus den Samples funktionieren würde. Aber das ist schon Frust.

Danke für die Hilfe

:angry4:
Beste Grüße
Wolfgang

Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
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: XbpPresSpace und GRAxxx []

Beitrag von brandelh »

Was willst du denn machen ?

Ein Butten erzeugt Linien auf einem anderen oder auf dem Bereich außen herum ?

In diesem Beispiel wird ownerdrawing eingesetzt, um die Textfarbe des Buttons selbst zu bestimmen, natürlich könnte man da auch Linien malen - AUF DEM BUTTON !
oPS wird hierbei von Xbase++ automatisch an draw() übergeben, da muss man nichts selbst machen: METHOD HBColorButton:draw( oPS, aInfo ) siehe _test.prg

Wenn dein Button Linien außerhalb von sich selbst zeichnen soll, muss eine Beschränkung auf seine eigene Größe aufgehoben werden, siehe dazu clipSibblings()

Und immer schön beachten zu welcher Klasse eine Methode gehört: XbpWindow:unlockPS()

Code: Alles auswählen

oPS := drawingArea:lockPS()
...
 oPS:unlockPS()
richtig ist dass die drawingArea blockiert wird, diese muss auch wieder freigegeben werden. oPS kann ein destroy() vertragen (denke ich mal) ...
So sollte es richtig sein:

Code: Alles auswählen

oPS := drawingArea:lockPS()
...
oPS:destroy()
...
drawingArea:unlockPS()
Ich bin mir sicher, dass ich einen Button hatte, der mit Farblinen um sich herum verschiedene Zustände anzeigt, ich muss mal suchen gehen.
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: XbpPresSpace und GRAxxx []

Beitrag von AUGE_OHR »

moin,
Wolfgang_B hat geschrieben: Mo, 16. Jul 2018 13:15 ich versuche gerade eine Linie in ein oDlg-Objekt zu zeichnen. Es gelingt mir aber nicht.
zunächst mal XbpPresSpace():new() --> oPS hat KEINE weiteren Parameter :!:

wenn du den oPS von einem XbPart haben willst wäre ist es normal

Code: Alles auswählen

XbpWindow():lockPS() --> oPresSpace 
wie Hubert schon sagte

Code: Alles auswählen

  oPS := drawingArea:lockPS()
  GraLine( oPS, {10,50}, {100,200} )  // diagonal ? von x,y nach x,y
  oPS:unlockPS()
sollte dann funktionieren ... bis du es mit einem anderen Fenster "überdeckst".
wenn das Fenster wieder den Focus bekommt wird deine GraLine() vermutlich nicht wiederhergestellt :(

die o:drawingArea ist gut als Parent für XbParts aber NICHT für GRA Function :!:

Hubert spach den o:Draw Callback Slot an den auch ein XbpStatic hat.
du nimmst also eine XbpStatic als "Linie". Breite ist klar und Höhe 1-3 Pixel (je nach Linie Type)
XbpStatic()
Slot: :draw := { |oPS,aInfo,oSelf| MyDraw(oPS,aInfo,oSelf) }

Code: Alles auswählen

FUNCTION MyDraw( oPS, aInfo, oSelf)
LOCAL aRect := aInfo [XBP_DRAWINFO_RECT]
LOCAL aAttr := Array( GRA_AL_COUNT ) // Array für Linien- 
                                     // attribute 

  aAttr[ GRA_AL_TYPE ] := GRA_LINETYPE_SOLID  
  aAttr[ GRA_AL_WIDTH] := aRect[4]-aRect[2]
  GraSetAttrLine( oPS, aAttr )     // Attribute setzen 

  GraLine( oPS, {aRect[1],aRect[2]}, {aRect[3],aRect[4]} )

// Ist der Rückgabewert hingegen .F. (falsch) findet keine weitere Bearbeitung der Nachricht statt
RETURN .F.
so ein "Linie" würde sich jedes mal neu malen wenn nötig.

---

nun hast du sicherlich mehr als nur eine Linie in deinem Fenster sprich andere XbParts :-"

wenn du nun ein "grosses" XbpStatic nimmst das als Parent für alle deine XbParts gilt dann kannst du es als Hintergrund mit mehrere GRA Functionen nehmen.

Code: Alles auswählen

  GraLine( oPS, {10, 50}, {100, 50} )
  GraLine( oPS, {10,150}, {100,150} )
auch für ein Hintergrund-Bild (Formular) wäre der o:Draw Slot der richtige Ort

Code: Alles auswählen

  oBmp:draw( oPS, {aRect[1],aRect[2],aRect[3],aRect[4]},;
                  {0,0,oBmp:xSize,oBmp:ySize} )
und wenn das XbpStatic grösser o:DrawingArea ist kann man die XbpStatic auch im Fenster "scrollbar" machen ;).
gruss by OHR
Jimmy
Benutzeravatar
Wolfgang_B
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 484
Registriert: Do, 14. Jun 2007 18:22
Wohnort: 94065 Waldkirchen
Hat sich bedankt: 14 Mal
Danksagung erhalten: 5 Mal

Re: XbpPresSpace und GRAxxx []

Beitrag von Wolfgang_B »

ich wollte mich in das Thema einarbeiten um z.B. Temperaturverläufe oder auch farbige PB darstellen zu können. Leider sind die Beispiele dazu in den Samples und der Hilfe zum Lernen nicht besonders hilfreich.

Danke erstmal. Ich werde das alles mal ausprobieren. Manches ist mir jetzt aufgrund der Erklärungen schon klarer geworden.
Beste Grüße
Wolfgang

Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
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: XbpPresSpace und GRAxxx []

Beitrag von Tom »

Oh, Jesus. :roll:

Das hier erzeugt einen Dialog, in dem eine Linie diagonal mit GRA gezeichnet ist:

Code: Alles auswählen

   LOCAL oDlg, oPs
   oDlg          := XbpDialog():new( ,,{10,10}, {600,400},, .F. )
   oDlg:icon     := 1
   oDlg:taskList := .T.
   oDlg:title    := 'Test'
   oDlg:drawingArea:ClipChildren := .T.
   oDlg:create()
   oDlg:drawingArea:setFontCompoundName( FONT_DEFPROP_SMALL )
   oDlg:Show()

  * Linie zeichnen:
   oPS := oDlg:drawingArea:lockPS()
   GraLine( oPS, {10,50}, {100,200} )  
   oDlg:drawingArea:unlockPS()
Nicht vergessen: LockPS() und UnlockPS() werden nicht auf den Micro-PS angewendet, sondern auf den Part, dem er entspringt.

Diese Linie verschwindet tatsächlich, wenn das Fenster in den Hintergrund gerät und wieder nach vorne geholt wird, beim Vergrößern, Verkleinern, Minimieren und Maximieren. Um das Verschwinden zu verhindern, legt man das Zeichnen dieser Elemente in den Paint-Slot der DrawingArea:

Code: Alles auswählen

   oDlg:DrawingArea:Paint := {||MaleMeinZeug(oDlg)}
Hinweis: Der Codeblock bekommt als ersten Parameter die Koordinaten des Rechtecks und als dritten Parameter das Objekt selbst (in diesem Fall: die Drawingarea).

In "MaleMeinZeug" zeichnet man die GRA-Elemente. Das bewirkt, dass das Zeug jedes Mal neu gezeichnet wird, wenn es nötig wird, weil der Paint-Callback immer ausgelöst wird, wenn ein Neuzeichnen des Dialogs nötig wird.
Herzlich,
Tom
Benutzeravatar
Wolfgang_B
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 484
Registriert: Do, 14. Jun 2007 18:22
Wohnort: 94065 Waldkirchen
Hat sich bedankt: 14 Mal
Danksagung erhalten: 5 Mal

Re: XbpPresSpace und GRAxxx []

Beitrag von Wolfgang_B »

Merci nochmals. Tom, das wars!!
Beste Grüße
Wolfgang

Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von Tom »

@Wolfgang: Freut mich!

@Jimmy:
die o:drawingArea ist gut als Parent für XbParts aber NICHT für GRA Function
Ach. Echt? Sagt wer? Und, vor allem: Warum?
Herzlich,
Tom
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von AUGE_OHR »

Tom hat geschrieben: Di, 17. Jul 2018 17:59 Ach. Echt? Sagt wer? Und, vor allem: Warum?
die o:DrawingArea, genauer CLASS XbpIWindow(), ist ja eine abstrakte Klasse und deshalb in meinem Sinn kein Control.
es ist Xbase++ spezifische und würde, im Gegensatz zu einer XbpStatic, nicht mit anderen andern Compiler/Transpiler laufen.

---

o:Paint vs. o:Draw :
der Grund warum ich eine Static und den o:Draw Callback Slot bevorzuge liegt in den Parametern des Codeblock

Code: Alles auswählen

   XbpWindow():paint := {| aRect, uNIL, oSelf | ... } 
   XbpStatic():draw  := {| oPS, aInfo, oSelf | ... }
bei o:draw habe ich den oPS vorgegeben und muss mich nicht um ein "lock/unlock" kümmern.

Windows technisch gesehen :
bei o:paint greife ich auf WM_PAINT zurück während o:Draw auf WM_DRAWITEM reagiert.

ein WM_PAINT zu überschreiben, weil es re-Paint Probleme macht, ist eine "Reparatur"
WM_DRAWITEM dagegen ist für Ownerdraw also "gewollter" Eingriff auf DRAWITEMSTRUCT() / MEASUREITEMSTRUCT()
gruss by OHR
Jimmy
Benutzeravatar
Wolfgang_B
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 484
Registriert: Do, 14. Jun 2007 18:22
Wohnort: 94065 Waldkirchen
Hat sich bedankt: 14 Mal
Danksagung erhalten: 5 Mal

Re: XbpPresSpace und GRAxxx [erledigt]

Beitrag von Wolfgang_B »

Tom, doch nochmal eine Nachfrage..

Code: Alles auswählen

 oPS := oDlg:drawingArea:lockPS()
   GraLine( oPS, {10,50}, {100,200} )  
   oDlg:drawingArea:unlockPS()
heißt das, daß mit "lockPS" ein Presentationspace erzeugt wird? So wie ich das verstanden habe, muß immer erst ein Presentationspace erzeugt werden, bevor die GRAxx-Funktionen verwendet werden können?
Beste Grüße
Wolfgang

Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von Tom »

Oh, Jimmy.

Natürlich kann, darf und soll man auf einer DrawingArea malen. Dafür ist sie da, daher übrigens auch der Name: Zeichenbereich. Es mag sein, dass Du in irgendwelchen skurrilen Transpilersituationen damit nicht zurechtkommst, aber wenn Du hier behauptest, dass man das nicht tun sollte, dass das nicht gut wäre, dann stimmt das so einfach nicht.
Ja, die Draw-Slots liefern Dir bereits den Micro-PS, aber dafür musst Du Dich um sie gesondert kümmern. Wenn Du nach Deinem Paradigma einen Dialog haben wolltest, der GRA-Grafiken zeigt, müsstest Du mindestens ein Static darauflegen, das Du dann über den Draw-Slot bestücken könntest. Aber für den kleinen Vorteil, Dir den Presentation-Space nicht selbst holen zu müssen, hast Du hier unterschiedliche Zeichensituationen, auf die Du reagieren musst (DrawAction), vor allem aber hast Du ein Control mehr, als Du benötigst, und das musst Du resizen und platzieren usw. - völlig unnötigerweise. Denn für die Darstellung von Grafiken per GRA auf einem Dialog brauchst Du erst einmal nichts weiter als seine DrawingArea. Man kann auch einen XbpDialog in einem anderen platzieren, um so etwas zu machen. Gelegentlich tue ich so etwas, ohne das allergeringste Problem. XbpDialog-Objekte als Kinder von XbpDialog-Objekten können zuweilen ziemlich sinnvoll sein, nicht nur in diesem Kontext. Und kein Mensch verbietet so etwas.

Anders ist das, wenn die grafische Ausgabe im Verhältnis zu anderen Elementen stehen soll - Buttons, Eingabefeldern, was weiß ich. In dieser Situation ist es möglicherweise sinnvoller, einen gesonderte Parent für die Malerei zu generieren, der unabhängig von den anderen Elementen, aber im Verhältnis zu ihnen manipuliert werden kann. Das kann irgendein Static sein, aber auch ein Dialog. In dessen DrawingArea mit Paint gezeichnet wird. :wink:
Herzlich,
Tom
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von Tom »

Hallo, Wolfgang.
heißt das, daß mit "lockPS" ein Presentationspace erzeugt wird?
o:LockPs() liefert Dir den PresentationSpace von "o" für die grafische Ausgabe und sperrt ihn gleichzeitig für andere. o:UnlockPS() gibt ihn wieder frei. Es wäre sinnvoll, diese Operationen in eine Funktion oder Methode zu verlagern, die von o:Paint aufgerufen wird, damit automatisch neu gezeichnet wird, wenn es erforderlich wird (oder Du es mit einem o:InvalidateRect() auslösten möchtest).
Herzlich,
Tom
Benutzeravatar
Wolfgang_B
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 484
Registriert: Do, 14. Jun 2007 18:22
Wohnort: 94065 Waldkirchen
Hat sich bedankt: 14 Mal
Danksagung erhalten: 5 Mal

Re: XbpPresSpace und GRAxxx [erledigt]

Beitrag von Wolfgang_B »

danke!!
Beste Grüße
Wolfgang

Mitglied des Deutschsprachigen Xbase-Entwickler e. V.
Mitglied der XUG Osnabrück
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von AUGE_OHR »

gibt es bei FoxPro eine DrawingArea() :?:

das Wort hat nicht zu sagen da es das unter Windows nicht gibt.
ich würde wenn es ChildArea() nennen so wie ChildList()

---

ich bin gegen die "Verarsche" von Xbase++ wenn man die User etwas "vorgaukelt" was nicht Windows ist.
so wie du dich wegen meiner Apostrophe aufregst tu ich das bei "Zweckentfremdung" von Windows.

---

meine Masken sind in der Zeit immer grösser geworden, also musste ich die erweitern.
ein XbpStatic auf der o:DrawingArea als Parent gibt mir die Möglichkeit im Dialog zu scrollen.

---

habt ihr schon gemerkt das die Syntax

Code: Alles auswählen

   GraLine( oPS, {10,50}, {100,200} )
sicherlich nicht das ist was gewünscht war ...
DrawingArea_lockPS.jpg
DrawingArea_lockPS.jpg (29.92 KiB) 11770 mal betrachtet
soviel zum Thema ...
gruss by OHR
Jimmy
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: XbpPresSpace und GRAxxx [erledigt]

Beitrag von Koverhage »

ich bin gegen die "Verarsche" von Xbase++ wenn man die User etwas "vorgaukelt" was nicht Windows ist.
Warum arbeitest Du dann überhaupt noch damit ?

Deine Selbstdarstellung nervt eigentlich nur, zumal in längst erledigten Beiträgen.
Gruß
Klaus
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von brandelh »

Genau :!:

Da der Ersteller des Threads [erledigt] gesetzt hat, scheint er die gewünschte Antwort bekommen zu haben.

Was genau er wollte, habe ich zwar gefragt, wurde aber nicht beantwortet, oder ich habe es überlesen ... bei den vielen Sachen die man immer lesen soll :oops:

Entweder es geht um "Verzierungen" auf dem Button, dann wäre mein Beispiel oben mit dem OwnerDrawing die richtige Vorgehensweise, denn dies hat Alaska so vorgesehen.
ODER es geht um Linien die über den Button hinaus sollen, dann muss man die drawingArea bemühen und das clipping beachten, normalerweise spart die ja die controls aus (clipChildren).

Auf jeden Fall ist die drawingArea nichts anderes als ein weiteres Fenster, das Alaska mit Xbase++ nutzt um die interne Zeichenfläche vom Rand zu trennen,
dabei erfinden sie keine "nicht Windows Teile", sondern nutzen genau das was Windows ausmacht, FENSTER ... wenn man den Klassenbaum durchsieht, kann man die Abhängigkeiten schön sehen.

Andere Sprachen mögen das anders organisieren, aber in Windows ist alles von Microsoft, was über die API von Windows angesprochen wird.
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von AUGE_OHR »

Koverhage hat geschrieben: Do, 19. Jul 2018 7:59 Warum arbeitest Du dann überhaupt noch damit ?
es geht um die spezifische Bezeichnung von Dingen und nicht um die Sprache an und für sich [-X

Xbase++ baut auf Windows auf und deshalb sollte man über den Xbase++ "Tellerrand" sehen.
was andere Compiler/Transpiler angeht gehört eben auch zur xBase Welt die "hinter dem Horizont" erscheinen :roll:
Koverhage hat geschrieben: Do, 19. Jul 2018 7:59 Deine Selbstdarstellung nervt eigentlich nur
AHA ... was ist daran verkehrt auf einem erweiterten Level zu arbeiten :?:

das ich meiner Erkenntnisse hier poste liegt daran das ich die Erfahrung mit anderen teilen will was sich in Form von Source Code, Demos oder Snapshot mache.
gruss by OHR
Jimmy
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von AUGE_OHR »

brandelh hat geschrieben: Do, 19. Jul 2018 8:06 Da der Ersteller des Threads [erledigt] gesetzt hat, scheint er die gewünschte Antwort bekommen zu haben.
das ist richtig aber eine Antwort zu Toms "oh" Msg stand aus ... so wie jetzt eine Antwort
gruss by OHR
Jimmy
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von Tom »

Ach, Jimmy. :)

Scrollende Dialoge (übrigens eigentlich ein No-Go bei guter Windows-Programmierung) und Draw-Methoden, die eigentlich fürs Ownerdrawing gedacht sind, während es hier um schlichte, grafische Ausgaben geht - geschenkt. Du lebst in Deiner Welt, der Rest in der anderen. :wink: Ist schon okay. Sind ja immerhin interessante Diskussionen.
habt ihr schon gemerkt das die Syntax
GraLine( oPS, {10,50}, {100,200} )
sicherlich nicht das ist was gewünscht war ...
Warum nicht? Es soll eine (diagonale) Linie von X 10 und Y 50 nach X 100 und Y 200 gezeichnet werden, und genau das passiert auch. Oder was?
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von Jan »

Tom hat geschrieben: Do, 19. Jul 2018 9:28
habt ihr schon gemerkt das die Syntax
GraLine( oPS, {10,50}, {100,200} )
sicherlich nicht das ist was gewünscht war ...
Warum nicht? Es soll eine (diagonale) Linie von X 10 und Y 50 nach X 100 und Y 200 gezeichnet werden, und genau das passiert auch. Oder was?
Ich hatte mich auch gefragt, was Jimmy damit sibyllisch anmerken wollte. Das Einzige, was mir auffällt, ist, das Jimmy Xbase++ Standard = BottomLeft nutzt. Bei mir sähe das anders aus, da ich grundsätzlich nur TopLeft arbeite in Dialogen und Ausdrucken.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von AUGE_OHR »

Tom hat geschrieben: Do, 19. Jul 2018 9:28 Scrollende Dialoge (übrigens eigentlich ein No-Go bei guter Windows-Programmierung)
das ist IMHO überholt da man früher kein "Scale" Faktor oder "Zoom" hatte

sobald ein Fenster, wie bei einen Browser, "zoombar" ist sind Scrollende Dialoge das übliche.
Tom hat geschrieben:Oder was?
naja ... so eine diagonale Linie schreit doch danach zu fragen ob "das" wirklich gewollt ist :?:
gruss by OHR
Jimmy
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: XbpPresSpace und GRAxxx [erledigt]

Beitrag von Jan »

AUGE_OHR hat geschrieben: Do, 19. Jul 2018 9:48
Tom hat geschrieben:Oder was?
naja ... so eine diagonale Linie schreit doch danach zu fragen ob "das" wirklich gewollt ist :?:
Jimmy,

ich kann Dir noch immer nicht folgen. Wenn Du Die Koordinaten für eine diagonale Linie angibst, dann würde ich durchaus erwarten, das da eine diagonale Linie gezeichnet wird.

Erzähl doch mal, was Dich daran stört. Statt uns hier im trüben rumstochern zu lassen.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Antworten