Anchors akRight in DX10 Seattle defekt ???

[arnof]

Hi,

ich transferiere gerade alle meinen historischen Apps zu DX10, hierbei ist mir aufgefallen das mit den Anchors und speziell der akRight in Zusammenhang mit Tabs überhaupt nicht funktioniert!

Objekte sind überall nur nicht im sichtbaren Bereich :kotz: Natürlich ist mir das erst nach dem erfolgreichen Review aufgefallen :pale:

[arnof]

Irgendwie schon traurig, das man Grundlagen, die mind. seit XE5 funktioniert hatten nun wieder so nachbauen muss:

Code:

procedure TFM_form.TabControl1Resize(Sender: TObject);
 var i:integer;
      ed:TEdit;
begin
 for i := 1 to 7 do begin
  try
   ed:=FindComponent('Edit'+IntToStr(i)) as TEdit;
   ed.Width:=TabControl1.Width-ed.Position.X-5;
  finally
  end;
 end;
end;

[arnof]

Bug an Bug ....Grundlagen ...

Nun teste ich mal mit meinem alten 3Gs (wegen kleinen Bildschirm und Positionierung.....

Nun drehe ich einfach mal den Bildschirm, so das nicht mehr alles reinpasst und ich stelle Ihn wieder hochkant ....

Nun sind alle Komponenten nicht mehr sichtbar, die im Querformat nicht sichtbar waren :roll: Erst ein Tabwechsel zeigt die Elemente wieder an.

Testet überhaupt jemand bei Emba ????



Update: das mit dem drehen scheint unter iOS9 zu funktionieren ...

[Thomas Horstmann]

Evtl. ist es dieses Problem:

https://quality.embarcadero.com/browse/RSP-11895

Falls ja, hilft nur ein Panel (mit alClient) in den Tab zu legen und dort die Objekte zu platzieren. Dann läuft akRight.

[arnof]

Zitat:

Zitat von Thomas Horstmann (Beitrag 1318314)

Evtl. ist es dieses Problem:

https://quality.embarcadero.com/browse/RSP-11895

Falls ja, hilft nur ein Panel (mit alClient) in den Tab zu legen und dort die Objekte zu platzieren. Dann läuft akRight.

ja hört sich so an. .....

[Rollo62]

Hallo arnof,

ja ich kenne die Probleme das sich selbst die Basics-Standardkomponenten sich falsch verhalten in verschiedenen Plattformen,
oder erstmal gelernt werden muss was geht und was nicht.

Ich habe z.B. die ListView repariert und mir dazu die FMX.ListView.pas ins eigene Projekt kopiert
als Workaround.

Wie wäre es wenn man soetwas wie bei JavaScript machen würde:
Da gibt es Polyfills, die fehlende, problematische Funktionen nachbilden solange bis es im Standard korrekt läuft.

Das könnten wir doch sicher auch machen, und die "BugFixes" irgendwo zusammenlegen, so dass man
sich endlich wieder auf die Anwendungsentwicklung konzentrieren kann.

Wenn Emba die Units nicht verbessert dann muss man das eben selber tun.

Vielleicht hat ja jemand einen Vorschlag wo und wie man das machen könnte.
Es könnte ja auch hier im Forum sein, wo solche Workarounds in einem separatem Folder gespeichert werden.
Oder ein public GitHub Verzeichnis ?

Ich wäre auf jeden Fall dabei wenn es soeine zentrale Anlaufstelle geben würde.
Die Frage ist vielleicht noch w.g. der Lizenzen der Units, darf man die so einfach ändern und posten ?
Da muss dann Embarcadero (oder wie die jetzt heissen) mitspielen.

Rollo

[Sherlock]

Ist das ein VCL oder ein FMX-Problem? Oder können das plötzlich beide nicht mehr?

Sherlock

[Stevie]

Zitat:

Zitat von Rollo62 (Beitrag 1318373)

Die Frage ist vielleicht noch w.g. der Lizenzen der Units, darf man die so einfach ändern und posten ?

Nein, darf man nicht.

Zitat:

Zitat von Rollo62 (Beitrag 1318373)

Da muss dann Embarcadero (oder wie die jetzt heissen) mitspielen.

Die heißen immernoch so und nein, das werden die mit Sicherheit nicht.

[Rollo62]

Hallo Stevie,

dann könnten es aber Patches für die orginalen FMX... Files sein, das ist ja wohl nicht verboten.
Allerdings wüsste ich nicht wie man das sinnvoll pflegen könnte.
Vielleicht kennt ja jemand eine Platform wo das bequem funktioniert ?
Könnte GIT eine Lösung sein, in der nur die Änderungen einfliessen aber nicht das gesamte Orginal,
und beim Checkout werden meine Orginaldateien gepatcht.
Geht sowas, das sollte doch den Lizenzen nicht entgegensprechen ?

Jedenfalls muss man sich doch irgendwie selber helfen, denn bis Embarcadero etwas gefixt hat
gehen wohl einige Versionen ins Land.

Rollo

[stahli]

Frag doch mal bei MEissing an.
Wenn Dritte die Bugs fixen und das bereit stellen sollte Emba doch froh sein (könnten das ja auch selbst übernehmen).

[MEissing]

...genau dafür ist das Quality-Portal da.

(Kunden mit einem aktiven Support-Vertrag/Update Subscription können sich natürlich auch direkt an den Support wenden)

[Rollo62]

Hallo Matthias,

nichts für ungut, aber manche BugFixes sind mit ein paar Zeilen repariert.
Da kann ich kaum extra einen QC case für ausmachen, das kostet mehr Aufwand als Nutzen.
Und selbst wenn, dann dauert es mindestens bis zur nächsten Vollversion bis da etwas passiert ist.
Der Support kann mir auch nur helfen wenn ich etwas falsch anwende, ich rede hier von "Bugs" die
offensichtlich sind.

Wenn man mal zu anderen OpenSource Plattformen schaut wie schnell dort die Community Probleme beseitigen und
auch neue Features beitragen kann kann werde ich regelmäßig neidisch.
Wäre gut wenn Embarcadero sich da auch mal etwas mit mehr Nutzerbeteiligung einfallen liesse, an der Community
liegt es ja offensichtlich nicht, wenn mir mir das tolle Forum hier ansehe.

EDIT:

Zitat:

...genau dafür ist das Quality-Portal da.

Wenn das dafür gedacht ist: Bitte.
Aber wie bekomme ich dann immer die aktuellsten Patches in meine FMX.Sourcen ?
Ich habe ehrlich keine Lust Problem für Problem durchzugehen, sondern ich muss ich eigentlich mal wieder um die
Anwendungsentwicklung kümmern.

Wenn QC das leisten soll dann müssten die Workarounds doch irgendwie als Paket (da bin ich wieder bei Git) verteilt werden,
und könnten später dann in die neue Version einfliessen.
Dann wäre das ganz in meinem Sinn.






Rollo

[bra]

Zitat:

Zitat von Rollo62 (Beitrag 1318560)

nichts für ungut, aber manche BugFixes sind mit ein paar Zeilen repariert.
Da kann ich kaum extra einen QC case für ausmachen, das kostet mehr Aufwand als Nutzen.

Andererseits ist es nun mal die zentrale Anlaufstelle für Bugs, in die sowohl die Anwender als auch die Embarcadero-Leute reinschauen. Wenn man selbst stundenlang nach einer Lösung sucht, die jemand anders schon ewig behoben hat, wäre ein Eintrag im QC schon hilfreich.

[MEissing]

Zitat:

Zitat von Rollo62 (Beitrag 1318560)

Da kann ich kaum extra einen QC case für ausmachen, das kostet mehr Aufwand als Nutzen.

Ah.

....und "die" OpenSource-Projekte arbeiten dann wie?

[Stevie]

Zitat:

Zitat von MEissing (Beitrag 1318563)

Zitat:

Zitat von Rollo62 (Beitrag 1318560)

Da kann ich kaum extra einen QC case für ausmachen, das kostet mehr Aufwand als Nutzen.

Ah.

....und "die" OpenSource-Projekte arbeiten dann wie?

Pull-Requests mit dem Fix drin.

Das lässt sich aber leider nicht auf alles anwenden, denn bei größeren Änderungen reicht das allein nicht.

@Rollo62:
Ein QP Ticket zu eröffnen, erfordert aber kaum mehr Aufwand, als hier im Forum nen Post zu verfassen - das ist ne ärmliche Ausrede.

[Rollo62]

Mein Problem damit ist das man munter QC'S produzieren kann, ich finde
aber eher selten Lösungen.

Später kann ich die von Emba dann nachkaufen ...

Ich brauche aber in der Regel sofort eine Lösung.
ausserdem möchte ich nicht 80% meiner Zeit Fehlersuchen, sondern einfach den "NightlyBuild" des Frameworks nutzen und
nur mit meinen speziellen Problemen dann zum QC kommen.

Es gibt eben keinen solchen "NighltyBuild" mit allen Verbesserungen, d.h. es gibt wohl Upd1 alle Vierteljahre.
Aber so lange kann Niemand warten, also frickelt sich jeder selber seine "Lösung" zusammen, statt das es einen vernünftigen
Workflow, Diskussion und zeitnahen Resolve gibt.

Wie oft sehe ich das gleiche Problem hier zigmal in verschiedenen Varianten im Forum auftauchen, statt es einmal zu erledigen.

Rollo

[Stevie]

Erstens kannst du nicht einfach Nightly Builds von Delphi oder seinen Bibliotheken liefern ohne erheblichen Mehraufwand der Entwicklung - die müssen nämlich dann sicherstellen, dass es keine Interface Änderungen gibt, sonst fliegt dir möglicherweise alles um die Ohren. Und als nächstes kommen dann irgendwelche neuen QP Einträge, dass was nicht funktioniert, weil man sich nen Nightly Build installiert hat.

Wer schonmal ein etwas umfangreicheres Projekt über einen längeren Zeitraum entwickelt und deployed hat, der weiß, dass das kein Kindergeburtstag ist, wo man mal ebend nightly builds raushauen kann (außer man will sich laufend das System komplett von null mit einem solchen Build aufsetzen mit der Gefahr, dass es sowieso nicht läuft).

P.S. Wo gibts eigentlich nochmal die Nightly builds von .NET? :stupid:

[Rollo62]

Ich meine ja nur das es eine schnelle Lösung für solche einfachen Standardprobleme des Frameworks geben sollte, wie auch immer.
Diese sollten einen schnellen Fortschritt ermöglichen und Vermeiden das zig Entwickler immer in dasselbe Problem laufen.
Wie gesagt, wenn ich keine Updates erhalte muss ich eben selber patchen, und das tun womöglich alle Entwickler.

Früher mit VCL war das kein Problem, aber mit FMX hat sich halt alles potenziert, ich finde da sollte man
nicht so weitermachen wie bisher.

QC war zumindest so das ich Workarounds finden konnte, in Jira finde ich aber nur die BugReports und Diskussionen darum,
Mag sein das ich mich irre, aber ich finde Jira nicht besonders effektiv, zumal ich keinen schnelle Lösung bekomme.
Wenn schon kein schneller Workflow möglich ist, vielleicht sollte Emba dann überlegen uns fürs BugMelden und Workaround-Fixing zu entlohnen,
damit man das auch wirtschaftlich verantworten kann.
Z.B. könnte es virtuelle FixPoints geben (nicht zu verwechseln mit BitCoins), die beim Update angerechnet werden können.
Aber so progressiv wird man wohl nicht vorgehen ...

Rollo

[mquadrat]

Bug selber fixen ohne Meldung -> bei der nächsten Hauptversion muss man nachschauen, ob gefixt oder man muss es wieder selber machen
Bug selber fixen und Meldung im QP -> bei der nächsten Hauptversion schauen, ob der QP zu ist, wenn nicht nochmal selber machen

Vorteil: Man kann die Meldungen in der QP viel schneller durchgehen, als sich die neuen Sourcen anzuschauen -> Zeitersparnis trotz Meldung

Mal in der Kurzversion.

Bei Shopware mache ich grad auch nichts anderes. Selber fixen und melden. Und wenn mal wirklich mehr Zeit übrig bleibt: Pull Request. Da muss man aber eben auch alle anderen Use-Cases berücksichtigen und nicht nur den eigenen wie beim Quick'n'Dirty Fix.

[arnof]

Also als erstes mal getestet nach dem Update und:

natürlich ist der Bug noch da .....

Nun habe ich mein Problem mit Align gelöst.

[Sir Rufo]

Zitat:

Zitat von arnof (Beitrag 1321985)

Also als erstes mal getestet nach dem Update und:

natürlich ist der Bug noch da .....

Nun habe ich mein Problem mit Align gelöst.

Es waren einfach nicht genug Votes auf deinem Bug-Report :stupid:

Meine gemeldeten Bugs sind auch nicht behoben ... aber wer will schon Tasks (vernünftig) oder einen Http-Request auf apple-OS abbrechen. Da muss man sich wohl vorher Gedanken zu machen :stupid:

[bra]

Zitat:

Zitat von Sir Rufo (Beitrag 1322001)

Meine gemeldeten Bugs sind auch nicht behoben ...

Macht nix, einer meiner Einträge ist angeblich mit Update 1 behoben, geändert wurde aber effektiv nix :roll: