Delphi-PRAXiS
Seite 2 von 7     12 34     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Die Delphi-IDE (https://www.delphipraxis.net/62-die-delphi-ide/)
-   -   Der XE8 Fehler-Thread (https://www.delphipraxis.net/184578-der-xe8-fehler-thread.html)

arnof 8. Apr 2015 22:13

AW: Der XE8 Fehler-Thread
 
Sollte nur ein Tipp gewesen sein, wir kommen wieder mal vom Thema ab!

Nun habe ich auch Bugs beizutragen:

TAndroidNativeLightSensor geht nicht mehr (zeigt nur noch 0 an)

TAndroidNativePressureSensor geht nicht mehr (zeigt nur noch 0 an)

Leicht nach vollziehbar Sensordemo starten mit XE7 gehts und mit XE8 gehts nicht mehr :pale:

Sir Rufo 8. Apr 2015 22:20

AW: Der XE8 Fehler-Thread
 
Zitat:

Zitat von arnof (Beitrag 1296815)
Sollte nur ein Tipp gewesen sein, wir kommen wieder mal vom Thema ab!

Aber wenn dein Tipp richtig ist, dann hat die Dokumentation doch einen Fehler und hier geht es doch um Fehler - ist ja der Fehler-Thread ... :stupid:

arnof 8. Apr 2015 22:41

AW: Der XE8 Fehler-Thread
 
Ja ja: bla bla bla ....

ok zum Thema:

mal schnell Debuggt wo der Käfer hängt:

FNativeSensor.DoStart; // das fehlt hier Arno

Das fehlt bei 3 Sensoren:

Magnetic, Pressure und Light

Delphi-Quellcode:
{ TAndroidNativeLightSensor }

constructor TAndroidNativeLightSensor.Create(AManager: TSensorManager);
begin
  inherited;
  FNativeSensor := TNativeSensor.Create(ASENSOR_TYPE_LIGHT);
  FNativeSensor.DoStart; // das fehlt hier Arno
end;

constructor TAndroidNativePressureSensor.Create(AManager: TSensorManager);
begin
  inherited;
  FNativeSensor := TNativeSensor.Create(ASENSOR_TYPE_PRESSURE);
  FNativeSensor.DoStart; // das fehlt hier Arno
end;

constructor TAndroidNativeMagneticSensor.Create(AManager: TSensorManager);
begin
  inherited;
  FNativeSensor := TNativeSensor.Create(ASENSOR_TYPE_MAGNETIC_FIELD);
  FNativeSensor.DoStart; // das fehlt hier Arno
end;

kaju74 9. Apr 2015 06:51

AW: Der XE8 Fehler-Thread
 
Liste der Anhänge anzeigen (Anzahl: 1)
Moin.

A/V beim Laden der Demo-App "MobileControls.dpr" (siehe Anhang).

LG,
Marc

kaju74 9. Apr 2015 07:03

AW: Der XE8 Fehler-Thread
 
Hi,

Die Demo-App "\Object Pascal\Mobile Samples\Media\MusicPlayer" wurde wohl auch nicht fertiggestellt. Zumindest fehlt die Implementierung von TMusicPlayer (Interface ist auskommentiert).

LG,
Marc

Daniel 9. Apr 2015 07:08

AW: Der XE8 Fehler-Thread
 
Das ist nicht schön - nur als Hinweis am Rande: Der Demo-Ordner von XE8 ist die lokale Kopie eines SVN-Repositories.
Solltest Du also einen SVN-Client wie z.B. Tortoise installiert haben, kannst Du das Verzeichnis aktualisieren.
Ich habe das eben getan: 64 neue Dateien, 6 wurden entfernt und 14 aktualisiert.

tueddy 9. Apr 2015 08:39

AW: Der XE8 Fehler-Thread
 
Zitat:

Zitat von Sir Rufo (Beitrag 1296814)
Zitat:

Zitat von arnof (Beitrag 1296810)
Dein Screenshot zeigt doch direkt das Problem an, das devmode: das ist der Treiberspeicher , der hier nicht da ist. Und hier solche Konstruktionen mit dem Druckertreiber auf undefiniert zu setzen, hier könnte man ja mal einen Zusammenhang herleiten ......8-)

Wo wird denn da was auf undefiniert gesetzt? Hab ich jetzt schon das rote Gemüse auf den Augen?

Kleiner Hinweis http://docwiki.embarcadero.com/Libra...r.PrinterIndex

Somit kommt sollte der Fehler wohl eher in dem Wrapper zu finden sein als in der sagenhaften Zeile
Delphi-Quellcode:
Printer.PrinterIndex := -1;

Der Fehler wird doch hier genau beschrieben + Fix:
http://qc.embarcadero.com/wc/qcmain.aspx?d=107919

Was mich nervt das Fehler berichtet werden inklusive FIX und sich bei Emb niemand darum kümmert. Hier wurde der Fehler berichtet am 14.08.2012.

Gerade habe ich diese Rückmeldung von JIRA zu einem anderen berichteten Fehler bekommen:
Code:
Re: [MacOS] System.ReportMemoryLeaksOnShutdown without function
As you reported, the documentation did not explain that this API member only worked on Windows. We have updated the documentation accordingly.
Das ist ja mal eine Super-Lösung: Anstelle der Fehlerbeseitigung wird einfach die Dokumentation entsprechend angepasst..

himitsu 9. Apr 2015 08:55

AW: Der XE8 Fehler-Thread
 
An der Stelle ließ es sich nicht schnell anders lösen.
In Windows wird FastMM verwendet, von welchem diese Funktion stammt.

Da müsste man dann auf die Idee kommen und noch ein Memory-Log dazwischenschalten, wobei der dann die Programme einen Hauch langsamer macht.
Oder man hätte die System-Speicheraufrufe vom FastMM entsprechend anpassen müssen, was ganz bestimmt auch möglich gewesen wäre. :gruebel:
Allerdings gibt es auch noch andere Third-Party-Memory-Debug-Komponenten.

Uwe Raabe 9. Apr 2015 09:17

AW: Der XE8 Fehler-Thread
 
Zitat:

Zitat von tueddy (Beitrag 1296859)
Gerade habe ich diese Rückmeldung von JIRA zu einem anderen berichteten Fehler bekommen:
Code:
Re: [MacOS] System.ReportMemoryLeaksOnShutdown without function
As you reported, the documentation did not explain that this API member only worked on Windows. We have updated the documentation accordingly.
Das ist ja mal eine Super-Lösung: Anstelle der Fehlerbeseitigung wird einfach die Dokumentation entsprechend angepasst..

In diesem Fall war ja auch die Dokumentation fehlerhaft, die offenbar suggerierte, daß ReportMemoryLeaksOnShutdown auch unter MacOS funktioniert. Der Fehler liegt also in der falschen Erwartung einer Funktionalität hervorgerufen durch ein Versäumnis in der Dokumentation. Diese Art der Fehlerbehebung kommt häufiger vor, als manche vielleicht denken. Das habe ich auch schon bei Autoherstellern erlebt.

tueddy 9. Apr 2015 10:01

AW: Der XE8 Fehler-Thread
 
Zitat:

Zitat von himitsu (Beitrag 1296861)
An der Stelle ließ es sich nicht schnell anders lösen.
In Windows wird FastMM verwendet, von welchem diese Funktion stammt.

?? FastMM4 in der aktuellen SVN Version kann Speicherleaks auch auf MacOS erkennen und anzeigen. Das funktioniert hervorragend.
Daher ist man jetzt nicht zwingend auf System.ReportMemoryLeaksAtShutdown angewiesen, wäre aber gut wenn das von Delphi transparent wie auf Windows funktionieren würde.

Viel schlimmer sind doch die gewaltigen (globalen) Leaks einer leeren MacOS FMX-Anwendung. Vielleicht scheut man sich bei Emb. genau deswegen davor:
Sehe ich keine Lecks sind sie auch nicht da..

Probiert das doch mal aus:

- Leere FMX Anwendung für MacOS
- FastMM4 aus SVN
- FullDebugMode einschalten
- libFastMM_FullDebugMode.dylib ins Deployment
- Detailierte .map Datei ins Deployment
- Anwendung starten und beenden

-> 20MB Logdatei mit Speicherlecks im AppBundle Ordner

Dieser Fehler wurde mehrfach berichtet, getan hat sich nichts:

RSP-9723 [MacOS] application gets terminated/Halt(0) on close. Incorrect unspooling
RSP-9726 Memory leaks in MacApi.ObjectiveC bridge
RSB-562 class destructor TVTableCache.Destroy is missing -> Memory leaks

kaju74 9. Apr 2015 10:36

AW: Der XE8 Fehler-Thread
 
Hi.

Nochwas:

Wenn man eine Unit per Dot-Notation einfügen will, funktioniert CodeInsight nach der Eingabe des "." nicht weiter.

Beispiel:

"FMX" eingeben und STRG+Space drücken, dann kommt die Vorschlagliste
"FMX." eingeben und STRG+Space drücke, es passiert nichts mehr

Man kann also nicht nur nach einem FMX Package suchen, wenn man nicht genau weiß, wie es heißt.

Gruß,
Marc

Insider2004 9. Apr 2015 10:52

AW: Der XE8 Fehler-Thread
 
Ich hoffe, ihr schreibt recht fleißig QCs!?

TRomano 9. Apr 2015 12:11

AW: Der XE8 Fehler-Thread
 
Diesen, ausgesprochen dumm formulierten, Beitrag hättest Du dir sparen können. Tut nichts zur Sache und man hat mehr und mehr den Eindruck, dass Du dich hier nicht "aufgehoben" fühlst. Dann solltest die Themen einfach nicht mehr lesen ...

Daniel 9. Apr 2015 12:14

AW: Der XE8 Fehler-Thread
 
Don't feed the trolls. ;-)
Davon abgesehen sollten wir tatsächlich schauen, was davon im QP ist und was dort noch hinein sollte.

TRomano 9. Apr 2015 12:19

AW: Der XE8 Fehler-Thread
 
Ist halt blos nervig ... Und natürlich sollte man die QC´s füttern, sonst haben die bei Emba doch nichts zu tun :)

Stevie 9. Apr 2015 13:05

AW: Der XE8 Fehler-Thread
 
In diesem Fall ist der Einwand berechtigt, gibt genügend Entwickler, die sich laufend über Fehler aufregen aber keinen vernünftigen Bugeintrag zustande bringen.

Im übrigen sollte man das QP füttern und nicht das QC.

TRomano 9. Apr 2015 13:08

AW: Der XE8 Fehler-Thread
 
Ich muss ja mal auch eine Lanze für Emba brechen. So schlimm, wie es teilweise und den Trolls dargestellt wird, ist es ja nicht. Ich kann zu mindestens unter der VCL ordentliche, verkaufbare, wartbare Software erstellen. Genau deshalb meckere ich auch nicht ständig. Aber ich warte meist ab, wie sich eine Version "entwickelt". Zu viel mehr habe ich auch gar keine Zeit ..

Darlo 9. Apr 2015 13:09

AW: Der XE8 Fehler-Thread
 
Bei mir führt SHIFT+Strg+F für "globales" Suchen selbst in Projekten mit nur 5 Units sehr oft zum Absturz der IDE.... Geht es nur mir so?

Darlo 9. Apr 2015 13:18

AW: Der XE8 Fehler-Thread
 
Beim Versuch für iOS 64 Bit (8.2) Ad-hoc zu compilieren erhalte ich folgenden Fehler:

[DCC Fehler] E2597 ld: file not found: libsqlite.a

himitsu 9. Apr 2015 13:28

AW: Der XE8 Fehler-Thread
 
Also bei mir geht es. Nur bei cnPack oder GExperts gibt es ein Problem, weil die irgendeine komische Funktion, welche meistens nichtmal was mach, auf diesen Shortcut gelegt haben. :wall:
Es gibt auch ein Problem mit umlauten (äöü usw.), wenn die Dateien geladen sind, dann geht es uns sonst wird es nicht gefunden. (seit Ewigkeiten bekannter Bug, bezüglich der Codierung beim Laden)

Wobei ich diese Suche auf das aktuelle Projekt, alle meine/fremde Quellcodes und auf alle RTL/VCL-Quellcodes loslasse.

tueddy 9. Apr 2015 14:01

AW: Der XE8 Fehler-Thread
 
Liste der Anhänge anzeigen (Anzahl: 1)
Speicherleck im VideoCapture Demo

tueddy 9. Apr 2015 14:05

AW: Der XE8 Fehler-Thread
 
Liste der Anhänge anzeigen (Anzahl: 1)
Dieser Fehler wurde auch schon berichtet (15.02.2015) und ist in XE8 Release nicht behoben (RSB-281, RSB-422 D2D errors in IDE).

Darlo 9. Apr 2015 15:18

AW: Der XE8 Fehler-Thread
 
Zitat:

Zitat von Darlo (Beitrag 1296918)
Beim Versuch für iOS 64 Bit (8.2) Ad-hoc zu compilieren erhalte ich folgenden Fehler:

[DCC Fehler] E2597 ld: file not found: libsqlite.a

Hierfür gibt es auch einen Report: RSP-10301
Leider ist der nur "offen".

himitsu 10. Apr 2015 10:18

AW: Der XE8 Fehler-Thread
 
Liste der Anhänge anzeigen (Anzahl: 1)
Naja, also cnPack bekommt das besser hin. :roll:
Anhang 42893

In wie weit das von der Geschwindigkeit und vorallem dem Flackerverhalten (auch via RDP) benutzbar ist, werd' ich heute abend mal über ein langsameres RDP probieren.
(Lokal und im schnellen LAN geht es halbwegs, aber das aus'm CnPack war via schnellem Internet absolut nicht ertragbar, ohne gleich einen epileptischen Anfall befürchten zu müssen)

Warum ist das eigentlich englisch, in einem deutschen Delphi?

Daniel 10. Apr 2015 10:24

AW: Der XE8 Fehler-Thread
 
Zum Thema "Castalia" und Flackern. Das wirkt sich auf unterschiedlichen Systemen unterschiedlich aus, in der Beta-Phase konnten einige Benutzer dieses Problem gar nicht nachstellen, während es für andere permanent auftrat.

Über die Einstellungen lässt sich das Verhalten aber steuern: Unter "Editor" --> "Integration" findet sich die Option "Use editor graphics buffer", die per Standard den Wert "no" hat. Aktiviert man diese Option, hat sich das Flackern in den meisten Fällen spürbar beruhigt. Einen Versuch ist es jedenfalls wert.

mkinzler 10. Apr 2015 10:26

AW: Der XE8 Fehler-Thread
 
Und beim CnPack sollte eine Deinstallation und Neuinstallation statt Update das Problem beheben.

eddie11 10. Apr 2015 12:34

AW: Der XE8 Fehler-Thread
 
Hi allerseits,

ich habe mal die Plattform-Controls TEdit, TButton und TSwich ausprobiert (ControlType=Platform). Auf den ersten Blick sind die chic, ich glaube das ist der richtige Weg - wenn es denn funktionieren würde...

Wenn ich z.B. ein TPanel oder TRectangle oder irgend ein anderes Control darüberlege, dann bleiben die Platform-Controls auf dem Gerät sicht- und benutzbar als ob sie vor dem Panel oder Rectangle wären, bei ControlType=Styled ist das nicht so.

Ist das jetzt ein Fehler oder ist das ein Feature... :roll:
...oder muss ich da noch irgend ein Property zusätzlich setzen?

milos 10. Apr 2015 12:46

AW: Der XE8 Fehler-Thread
 
Liste der Anhänge anzeigen (Anzahl: 1)
Hat sonst noch jemand ein Problem, dass manchmal CTRL + Z nicht funktioniert?

Freundliche Grüsse

Edit: Bild hochgeladen *hust :?*

Der schöne Günther 10. Apr 2015 12:48

AW: Der XE8 Fehler-Thread
 
Zitat:

Zitat von eddie11 (Beitrag 1297049)
Ist das jetzt ein Fehler oder ist das ein Feature...


Ich hab mit FMX nichts am Hut, aber soweit ich weiß ist das eine bekannte Einschränkung. Damit wird man leben müssen.

Darlo 10. Apr 2015 12:50

AW: Der XE8 Fehler-Thread
 
Zitat:

Zitat von eddie11 (Beitrag 1297049)
Hi allerseits,

ich habe mal die Plattform-Controls TEdit, TButton und TSwich ausprobiert (ControlType=Platform). Auf den ersten Blick sind die chic, ich glaube das ist der richtige Weg - wenn es denn funktionieren würde...

Wenn ich z.B. ein TPanel oder TRectangle oder irgend ein anderes Control darüberlege, dann bleiben die Platform-Controls auf dem Gerät sicht- und benutzbar als ob sie vor dem Panel oder Rectangle wären, bei ControlType=Styled ist das nicht so.

Ist das jetzt ein Fehler oder ist das ein Feature... :roll:
...oder muss ich da noch irgend ein Property zusätzlich setzen?

Hi, das ist bekannt und z.B. bei TMS iCL ebenso. Es liegt an der Z-Order. Native Komponenten sind immer onTop. Habe jetzt auf die schnelle keinen Link hier, ist aber in der Doku erklärt.
Leider funktioniert beim "nativen" TEdit der clearingbutton nicht.

uligerhardt 10. Apr 2015 12:57

AW: Der XE8 Fehler-Thread
 
Zitat:

Zitat von Darlo (Beitrag 1297058)
Hi, das ist bekannt und z.B. bei TMS iCL ebenso. Es liegt an der Z-Order. Native Komponenten sind immer onTop. Habe jetzt auf die schnelle keinen Link hier, ist aber in der Doku erklärt.
Leider funktioniert beim "nativen" TEdit der clearingbutton nicht.

Ist irgendwie auch logisch - dürfte das gleiche sein wie in der VCL bei TGraphicControl und TWinControl. Alle VCL-TGraphicControls oder nicht-nativen FMX-Controls werden direkt auf den Formhintergrund gemalt.

Sir Rufo 10. Apr 2015 13:36

AW: Der XE8 Fehler-Thread
 
Ist schon mal irgendwo gemeldet worden, dass der Bereistellungs-Manager falsch dokumentiert ist, bzw. unerwartet reagiert?

Laut Erstellen einer Android-App fügt man die Datei hinzu, vergibt den Remote-Pfad z.B. assets\internal oder assets und schon ist alles in Butter.

FALSCH

Es muss assets\ oder assets\internal\ lauten.

Und dann ist es noch entscheidend, welche Konfiguration man ausgewählt hat. Dateien die man mit der Auswahl Alle Konfigurationen hinzufügt, werden nicht übertragen. Es wird zwar hübsch angezeigt und vorgegaukelt, dass es übertragen wird ... ist aber nicht so.

Wenn man die ganz schmale Spalte direkt hinter Überschreiben etwas vergrößert, dann bekommt man die Spalte Konfiguration zu sehen. Steht dort der Eintrag Base, dann wird dieser Eintrag nicht übertragen.

Daniel 10. Apr 2015 13:54

AW: Der XE8 Fehler-Thread
 
Ja, der Bereitstellungsmanager ist ein Stück Software, mit dem einem nicht so schnell langweilig wird. Das ist leider auch mein Eindruck.

himitsu 10. Apr 2015 13:55

AW: Der XE8 Fehler-Thread
 
Zitat:

Zitat von Sir Rufo (Beitrag 1297070)
Wenn man die ganz schmale Spalte direkt hinter Überschreiben etwas vergrößert, dann bekommt man die Spalte Konfiguration zu sehen. Steht dort der Eintrag Base, dann wird dieser Eintrag nicht übertragen.

Vielleicht würde es dann auch mein Problemchen erklären, denn ich hab sowas, das für Alles gilt, natürlich in Base eingetragen. :stupid:
http://www.delphipraxis.net/184544-a...gabepfade.html

Sir Rufo 10. Apr 2015 13:57

AW: Der XE8 Fehler-Thread
 
Zitat:

Zitat von Daniel (Beitrag 1297074)
Ja, der Bereitstellungsmanager ist ein Stück Software, mit dem einem nicht so schnell langweilig wird. Das ist leider auch mein Eindruck.

Wenn es vernünftig dokumentiert wäre, kann der meinetwegen sein wie er ist/will, aber die Dokumentation ist falsch und unvollständig.

DeddyH 10. Apr 2015 14:26

AW: Der XE8 Fehler-Thread
 
Man verfügt eben derzeit über keine weiterführenden Informationen :mrgreen:

mkinzler 10. Apr 2015 14:27

AW: Der XE8 Fehler-Thread
 
Aber nur derzeit :mrgreen:

tueddy 10. Apr 2015 20:58

AW: Der XE8 Fehler-Thread
 
Liste der Anhänge anzeigen (Anzahl: 1)
MacOS - Einen hab' ich noch. Links FMX Controls, rechts native TMS Komponenten. Das ganze im MacOS Dark theme.
Immerhin wird jetzt beim Start einer Anwendung zwischen Mavericks und Yosemite Style unterschieden, das wars dann aber auch.
Das fehlende Auto-Umschalten ist gemeldet als RSP-10298

tueddy 13. Apr 2015 11:03

AW: Der XE8 Fehler-Thread
 
MacOS - Der Shortcut "CMD+Z" ist auf vertauscht mit "CMD+Y"
Das erinnert mich an die alten Bios-Zeiten: Möchten sie die Änderungen speichern (Strg+J)?
Strg+Y

https://quality.embarcadero.com/browse/RSP-10326
[MacOS]: Keyboard mapping ignored ( CMD+Z )

jaenicke 17. Apr 2015 15:45

AW: Der XE8 Fehler-Thread
 
Mal zur Speicherproblematik:
Ein Projekt mit 19k LOC und eins mit 29k LOC kompiliert, egal in welcher Reihenfolge, funktioniert und die IDE benutzt weniger RAM als XE7 (etwa 800 MiB). So weit so gut, aber das dritte Projekt führt dann zum Crash bei etwa 1 GiB benutztem RAM, fast egal welche Größe das Projekt hat.
--> "dcc exited with code 1" und eine leere MessageBox mit Ok/Abbrechen

XE8 stürzt jetzt schon bei geringerer Speicherauslastung ab als XE7, benutzt dafür aber auch weniger RAM als XE7 (aber immer noch rund 25% mehr als XE6), zumindest bei den bisher getesteten Projekten. Mal schauen...


Alle Zeitangaben in WEZ +1. Es ist jetzt 12:41 Uhr.
Seite 2 von 7     12 34     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz