|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Selfmade GUI Programmierung Tips? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| 1 -2- | [ - Beitrag schreiben - ] |
|
18.01.2014, 08:41 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: Fallbeispiel: Das Text-Objekt hat ein Attribut oxTx_text, mit dem ein neuer String reingesetzt werden kann. Wenn der nun aber etwas breiter aus fällt, wäre er zB neu zu zentrieren. Ich hab's so weit, dass sich das Fenster in seiner Größe live an neue Gegebenheiten an passen kann. Aber wenn ich während der Creationsphase mir dem selben Attribut einen Initialstring setzen will, dann geht das Resize ins Nirvana, weil noch kein Rastport für _LVOTextLenght() da ist. Daher frage ich im Dispatcher der Textklasse an dieser Stelle ab, ob das GUI 'wach' ist. Das gefällt mir nicht und ich überlege, da einen leeren Rastport zu haben, ohne Bitmap, nur minimal initialisiert mit InitRastport() oder so und mit Font-Zeiger. Wie würdest Du das machen? -- Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos". [ - Antworten - Zitieren - Direktlink - ] |
|
18.01.2014, 09:47 Uhr inq Posts: 445 Nutzer |
Andreas, du kannst das probieren mit IntuiTextLength(), dafür brauchst du nur den Font, den du benutzen willst und die Attribute (Fett, Italic). Das trägst du in eine struct.IntuiText ein und übergibst das IntuiTextLength(). Das kommt erkennbar aus intuition.library Gruß -- Config: A1200/30/50/FPU/SCSI/64MB, WinUAE/40/xx/xxMB, EUAE/40/25/xxMB, CDTV, CD32/SX32MK2/HD - AOS3.5 [ Dieser Beitrag wurde von inq am 18.01.2014 um 09:48 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
18.01.2014, 10:03 Uhr AGSzabo Posts: 1663 Nutzer |
@inq: Ah, auch eine Idee. Fehlt mir nur noch der Font aus den Prefs, solange ich keinen eigenen verwende.  -- Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos". [ - Antworten - Zitieren - Direktlink - ] |
|
18.01.2014, 21:16 Uhr inq Posts: 445 Nutzer |
Zitat: klick me Übrigens sehr verwunderlich, daß du nach über einem Jahr mit deinem Ox-Toolkit noch immer nicht weißt, woher du den Font bekommst, den du brauchst. Entweder du hast einen Screen oder du suchst dir einen oder du öffnest ihn selbst; in allen Fällen bekommst/lieferst du die nötige Fontinfo/Textattr oder was auch immer.  *EDIT: damals wars.... Aus deinem ersten Beitrag: Zitat:Hier ist das eigentliche Problem bzw. die Lösung. Mach' es anders! -- Config: A1200/30/50/FPU/SCSI/64MB, WinUAE/40/xx/xxMB, EUAE/40/25/xxMB, CDTV, CD32/SX32MK2/HD - AOS3.5 [ Dieser Beitrag wurde von inq am 18.01.2014 um 23:03 Uhr geändert. ] [ Dieser Beitrag wurde von inq am 19.01.2014 um 01:12 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
20.01.2014, 10:32 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wieso brauchst Du in dieser Phase einen „Resize“? Der Ablauf ist doch normalerweise so, dass Du zuerst des Text-Objekt anlegst und es dann mit einem Fenster assoziierst. Aber davon abgesehen gibt es doch gar keinen Grund, bei jeder Attributänderung die Fenstergröße neu zu berechnen. Schon gar nicht, wenn das Fenster überhaupt nicht sichtbar ist. Das ist letztendlich genau dasselbe wie mit dem Neuzeichnen, merke Dir einfach nur dass die Größe des Fenster neuberechnet werden muss und führe die Aktion aus, wenn alle anderen Operationen abgeschlossen sind (vor dem Neuzeichnen), aber frühestens wenn das Fenster wirklich sichtbar werden soll und somit der Screen feststeht. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
20.01.2014, 12:22 Uhr Thore Posts: 2266 Nutzer |
GUI Systeme aus anderen Systemen machen sowas oft mit einem "Invalidate" Flag. Das ist ein Wert, der bestimmt, ob ein Objekt neu gezeichnet werden muss. Passiert irgendwas z.B. Fenstergröße wird geändert, wird das Invalid-Flag gesetzt und das Objekt erkennt daran, daß es sich neu zeichnen muss. Natürlich zeichnen sie sich dann auch nur selbst, wenn sie selbst auf "Visible" stehen und das Fenster offen ist. Wenn eines der beiden nicht zutrifft, ist es dem Bildelement egal wie es aussieht. [ - Antworten - Zitieren - Direktlink - ] |
|
21.01.2014, 05:34 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ja, meine Vorredner haben es bereits erklärt. Warte mit dem Layouten bis das Objekt überhaupt sichtbar wird, oder zumindest bis das Fenster sichtbar wird. Es stellt sich auch noch eine andere Frage, das betrifft aber hauptsächlich den TextView, Label oder wie auch immer man es nennen will. Was passiert wenn der Text sich ändert, der mehr Platz braucht als bereits berechnet (weniger ist ja kein Problem). Bei Android (NTUI ist davon stark beeinflusst) ändert sich tatsächlich bei jeder Änderung auch das Layout des Dialogs. Bei NTUI mache ich das aber nicht. Alle Objekte müssen mit der Größe zurecht kommen, die sie beim Layouten bekommen haben. Wird der Text also länger, wird er abgeschnitten. Möchte der GUI Programmierer eine Änderung des Layouts, muss er es explizit aufrufen. Er muss dan auch damit rechnen, dass das Fenster vergrößert wird. Der Flow ist *obj = Create() # jederzeit CalculateSize() # screen ist gelocked, Fenster noch zu, berechnet minimale Größe Layout() # Fenster ist offen, setzt tatächliche Größe Draw() # Fenster ist offen, zeichne! (muss natürlich immer testen ob der Text passt) CalculateSize() wird aufgerufen, bevor ein Fenster geöffnet wird. Es berechnet rekursive die minimal notwendige Größe bis hoch zum Fenster. Das bestimmt dann auch wie klein man das Fenster sizen darf. Layout wird beim öffnen sofort danach aufgerufen, aber auch bei jedem Resizen oder sonstigen Aktionen, die das Layout beeinflussen. Draw wird jedesmal aufgerufen wenn gezeichnet werden muss. Das sind die unterschiedlichen Stufen, kann man alle mit "invalidate" oder dirty Flags versehen. Dadurch verhindert man, dass "teure" Berechnungen nur einmal ausgeführt werden, auch wenn während dem Programmablauf das sehr oft angefragt wird. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 21.01.2014 um 05:43 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
01.02.2014, 16:48 Uhr AGSzabo Posts: 1663 Nutzer |
Hello Again Jetzt geht es um die 'floattext' Klasse. Ein Text mit autom. Zeilenumbruch. Das bricht schon richtig um bei mir, aber mit der errechneten Mindesthöhe habe ich Probleme: Es gibt ein GETLAYOUT, kommt zuerst, und dann ein SETLAYOUT. Aber während ich im GETLAYOUT die die Höhe des umgebrochenen Textes bräuchte, kann ich diese erst im SETLAYOUT anhand der flexiblen Eingabebreite bestimmen. Mein floattext ist in einer view (virtueller scrollbarer Ausschnitt), mit welchem zusammen und mit einem scroller sich eine textview ergibt, ein auf und ab scrollbarer Text in einem Ausschnitt. Mein Ansatz wäre, beim GETLAYOUT in der floattext Klasse garnix zu tun, und beim SETLAYOUT anhand der da erhaltenen Breite die nötige Höhe errechnen. Dann nochmal irgendwie die view informieren, dass der floattext mehr Höhe braucht, so dass die view sich und den scroller richtig anpasst. Wie würdet ihr das machen? a -- Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos". [ - Antworten - Zitieren - Direktlink - ] |
|
01.02.2014, 18:09 Uhr Thore Posts: 2266 Nutzer |
Da hast Du viele verschiedene Möglichkeiten. Ich zeige mal 2 davon: Zeilenbasiert: Sind deine Strings (Zeilen) in einer verketteten Liste oder Objekte gespeichert, nimmst du für jede Zeile den höchsten Font und addierst diese nach dem Umbruch auf, plus die Offsets von Zeilenzwischenraum und Kopf und Fuß. Das ergibt die Höhe der Zeichenfläche. Seitenbasiert: Du hast eine Größe und die kannst vollsudeln. Ist die Größe überschritten, addierst Du nochmal diese Größe auf (als 2. Seite). Die Breite kannst ebenfalls adaptiv/dynamisch oder fix machen. Das kann sowohl das SetLayout auch das GetLayout berechnen, sofern er Zugriff auf das Objekt hat. Letztendlich ist es egal, wann es berechnet wird, sofern es vor dem Rendern passiert. Dann muss, richtig, die View informiert werden, dass sein Child sich geändert hat. [ Dieser Beitrag wurde von Thore am 01.02.2014 um 18:10 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
02.02.2014, 04:29 Uhr AGSzabo Posts: 1663 Nutzer |
Aha. Folgende Schwierigkeit: Der FloatText ist kein direktes Child der View, es hängt noch ein Rahmen dazwischen. Nun merkt der FloatText beim SetLayout wie hoch er ist. Er kann zwar die View informieren, aber diese würde in Reaktion ihre Childs, also den Rahmen anpassen wollen, an die neue Content-Höhe, und der Rahmen, da der FloatText ein Child des Rahmens ist, würde wieder den FloatText mit SetLayout an passen, der darauf wieder munter die View informiert. Was kann man da machen? -- Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos". [ - Antworten - Zitieren - Direktlink - ] |
|
02.02.2014, 10:54 Uhr AGSzabo Posts: 1663 Nutzer |
Ich hab's jetzt mal so: Wenn der FloatText basierend auf der vorgegebenen Breite seine erreichte Höhe berechnen und an die View zurücksenden soll, dann tut er das nur, wenn die Breite neu ist oder sich geändert hat. Das heißt, der FloatText bekommt das erste SetLayout, berechnet seine Höhe, weist die View an ein Re-Layout zu machen, dabei sendet die View wieder Get- und SetLayout an ihre Childs, auch letztendlich den Text, aber da passiert dann garnix weiter, weil die Höhe für die nochmal übergebene Breite schon berechnet wurde. Trotzdem kommt das SetLayout zweimal und wird auch in der View und in allen Objekten die zwischen View und FloatText hängen zweimal ausgeführt, aber ... wer eine bessere Idee hat, bitte melden.  -- Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos". [ - Antworten - Zitieren - Direktlink - ] |
|
03.02.2014, 07:41 Uhr Der_Wanderer Posts: 1229 Nutzer |
Grundsätzlich sollte jedes Objekt damit umgehen können, wenn es nicht die Größe bekommt die es braucht. Mein Rat wäre, berechne die Größe nicht vorher sondern erst beim Layouten (dein SETLAYOUT?). Wenn es nicht drauf passt, musst du (vertikale) Scroller anzeigen. Wenn es drauf passt, sind alle glücklich. Der Designer des Dialogs muss darauf achten, dass ein sinnvoller Platz dafür bereit steht. Im Falle des Float Textest kannst du die Situation nicht anders lösen. Beispiel: Dein Text wird mit "Hallo Welt." initialisiert. Nun gibts du dir wahnsinnig viel Mühle den Platzbedarf zu berechnen. Also nächstes setzt der App Programmierer den Text neu mit einer Abschrift der Bibel im Klingonischen Original. Und jetzt? EDIT: Wenn du bereits einen TextEditor hast, dann nimm einfach den und mache ihn Read-Only. Dann kann man den Text auch gleich markieren und kopieren. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 03.02.2014 um 07:54 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 12:58 Uhr AGSzabo Posts: 1663 Nutzer |
Es gibt 'GETLAYOUT' und 'SETLAYOUT'. Ersteres fragt wieviel Platz ein Objekt braucht, um die Fenstergröße zu berechnen, und letzteres sagt dann, wieviel Platz das Objekt letztendlich bekommt, zB beim Resizen des Fensters. Das TextView Problem habe ich jetzt gelöst. Neues Problem: Slider Langwort Pot/Body/Max reicht nicht! Ich habe ein riesiges File in einer Art HexEditor und will da durch scrollen. Dazu verwende ich den Offset direkt als Max des Scrollers. Das reicht nicht, der Scroller läuft über und der Knopf taucht nach der Hälfte wieder am Anfang auf. Eine Idee wäre, von vornherein eine herunterskalierte Größe für Max zu verwenden, dann weiß ich aber nicht, wie das bei kleinen Dateien wirkt, dass der Scroller da nicht springt? Bzw kann man dann bei kleinen Dateien noch fein scrollen oder nur in Schritten? -- Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos". [ Dieser Beitrag wurde von AGSzabo am 04.02.2014 um 12:59 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 13:31 Uhr Holger Posts: 8116 Nutzer |
Zitat:Was sagt Deine Textkomponente eigentlich, wenn sie nach der benötigten Breite gefragt wird? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 13:36 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wie wär’s, wenn Du zeilenweise scrollst und nicht pixelweise? Ich wüsste nicht, welchen Vorteil es für den Anwender hätte, in einem HexEditor um eine halbe Zeile scrollen zu können. Nichtsdestotrotz scheint mir entweder Dein Font zu groß oder die dargestellte Anzahl bytes pro Zeile zu klein, wenn Du solche Probleme hast. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 14:03 Uhr AGSzabo Posts: 1663 Nutzer |
Der FloatText sagt dass er eine setzbare Mindestbreite braucht. An sonsten gibt er nur die Höhe vor, die bei der zur Verfügung gestellten Breite resultiert. Nein, ich scrolle nicht in Pixeln sondern in Bytes. Zeilenweise scrollen ist zu grob. Aber da ich wortweise arbeite, kann ich da ganze schonmal um die Hälfte reduzieren. Mal sehn. Achja, PS PS: es wird zwar shon zeilenweise gescrollt, aber die horizontale Position ist mit der Tastatur einstellbar. -- Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos". [ Dieser Beitrag wurde von AGSzabo am 04.02.2014 um 14:04 Uhr geändert. ] [ Dieser Beitrag wurde von AGSzabo am 04.02.2014 um 14:07 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 15:29 Uhr Thore Posts: 2266 Nutzer |
Ein Langwort reicht nicht? 1 (unsigned) Long (32Bit) = 4294967296 Möglichkeiten/Einstellungswerte. Ob das nun Pixelzeilen sind oder Textzeilen... mir scheint der Wertebereich schon ausreichend groß. Bei einer 24 Punkt Schrift käme ich pixelweise immer noch auf 178956970 Textzeilen. So viel RAM kannst nicht reservieren wie Du hier Platz hättest Viele ältere Editoren arbeiten sogar nur im Word Bereich... Design-Fehler? [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 16:46 Uhr AGSzabo Posts: 1663 Nutzer |
@Thore: Aha, also ja, möglich, Designfehler. Ich vermute da auch schon etwas: Meine Formel zur Berechnung der grafischen Knob-Position multipliziert zuerst und dann dividiert sie. Vom Offset zur Knopfposition: knob_pos = ( gad_containter_pix_size - knob_pix_size ) * file_offset / ( file_size - visible_bytes) Von der Knopfposition (maus) zum effektiven Pot-Wert (Offset in File): file_offset = (file_size - visible_bytes) * knob_pixpos / (gad_containter_pix_size - knob_pix_size) Ich habe das so gemacht, damit keine Ungenauigkeit bei der Division entsteht. Oder? -- Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos". [ Dieser Beitrag wurde von AGSzabo am 04.02.2014 um 16:48 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 17:00 Uhr Thore Posts: 2266 Nutzer |
Du verrechnest Bytes mit Pixel-Size. Ist das gewollt? Ich rechne es später mal nach, bin noch unterwegs  [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 20:46 Uhr Thore Posts: 2266 Nutzer |
Von der Grundanordnung der Formel passts (also die Verhältnisrechnung), schau Dir nochmal die Werte an und rechne ggf mal mit Taschenrechner nach (Schreibtisch-Test). Da ich nicht weiß wie die Werte ermittelt werden, kann ich so auch nicht sagen warum Dir ein Long nicht reicht. Aber auch mit dieser Formel dürftest nicht so schnell an die Grenzen stoßen. Jetzt kommts drauf an was in den Variablen drinsteht und ob das stimmt. [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 21:06 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ja, Knopf Größen und solche Dinge sind ecklig zu berechnen. In NTUI wird daher der Offset eines Scroller nie in Pixel *gespeichert*. Pixelwerte sind immer nur temporär während dem Zeichnen. Dabei verwende ich Floats umd auf Nummer sicher zu gehen. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
27.07.2014, 10:03 Uhr AGSzabo Posts: 1663 Nutzer |
Bild: http://images.quicktunnels.net/xoxo_list.png Hi Für mein GUI brauche ich eine Liste wie oben sichtbar. Es soll einen Listentitel geben und einen Listenkörper. Das sind bei mir unterschiedliche einzelne Gadgets, die hier im Verbund wirken sollen. Das geht auch prima, meint man, bis man eine Spaltenbreite der Liste mit der Maus vergrößert (was noch geht) und dann aber das Fenster größer zieht. Jetzt meint das GUI, die neue Breite sei das neue Minimum. Warum? Weil sich Titel und Körper die Breitenwerte sharen. Bei der Minimumberechnung schauen beide nach, wer breiter ist, ein Listentitel oder eine Tabellenspalte und das breitere wird genommen. Nun verändert aber der Listentitel beim größerziehen einer Spalte deren Breitenwert, so dass auch der Listeninhalt mitrutscht, was ja beabsichtigt ist. Beim nächsten Gesamtlayout des Fensters nehmen der Titel und der Körper aber die neue Spaltenbreite als Minimum und die Listenbreite wächst. Sie wird nicht mehr kleiner. Was könnte ich da machen? Grüße A -- Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos". [ - Antworten - Zitieren - Direktlink - ] |
|
28.07.2014, 08:34 Uhr Thore Posts: 2266 Nutzer |
Ist es nicht normal so, daß jede Spalte ein "lokales" Minimum haben, und das Minimum der Liste sich eben daraus errechnet? Auch wenn das Fenster, bzw die Liste vergrößert wird, ändert sich an den lokalen Minima nichts. Das Minimum muss auch nicht auf die Breite der Elemente fixiert sein, sondern können sich auch überlappen. Deshalb würd ich das Minimum nicht berechnen sondern definieren (oder auch definierbar machen). Oder hab ich deine Frage falsch interpretiert? [ - Antworten - Zitieren - Direktlink - ] |
|
28.07.2014, 14:33 Uhr Holger Posts: 8116 Nutzer |
Zitat:Warum tun sie das? Was hat die aktuelle Breite mit dem Minimum zu tun? Das sind zwei verschiedene Größen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
| 1 -2- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Selfmade GUI Programmierung Tips? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|
