Was nervt euch so, während der Programmierung oder so allgemein

[Matze]

Zitat von Helmi:

Ich habe das Problem dass es für CNC-Programmierung keinen Editor gibt.
Das macht man mit einem ganz normalen Editor (Notpad, ...) und man merkt es erst, wenn man das Programm in der Maschine ablaufen lässt und dann der Interpretor einem die Fehlermeldungen um die Ohren haut

Nicht ganz richtig.
wir hatten in der FH einen NC-Editor, der das Fräsbild dann auch noch simulieren konnte.
Für CNC gibt's diverse kostenpflichtige Tools, die das ganze dann noch in 3D simulieren können.

Was mich zur Zeit nervt: Da "optimiere" ich einen Code und nachher dauert die Ausführung 3 x so lange wie vorher. Und ich habe nicht die geringste Ahnung wieso.
Und wenn man ein FPGA programmiert, dauert der Kompiliervorgang eine halbe Ewigkeit (aktuell ca. 12 Minuten). Bis der da endlich seinen Bit-Code erzeugt hat ...

[mkinzler]

Das könnte man auch durch die IDE automatisieren

[blackfin]

Zitat:

und man merkt es erst, wenn man das Programm in der Maschine ablaufen lässt und dann der Interpretor einem die Fehlermeldungen um die Ohren haut

Och, einfach immer schön mit G0 ins Werkstück, dann kann nix schiefgehen

[Helmi]

Zitat von Matze:

Zitat von Helmi:

Ich habe das Problem dass es für CNC-Programmierung keinen Editor gibt.
Das macht man mit einem ganz normalen Editor (Notpad, ...) und man merkt es erst, wenn man das Programm in der Maschine ablaufen lässt und dann der Interpretor einem die Fehlermeldungen um die Ohren haut

Nicht ganz richtig.
wir hatten in der FH einen NC-Editor, der das Fräsbild dann auch noch simulieren konnte.
Für CNC gibt's diverse kostenpflichtige Tools, die das ganze dann noch in 3D simulieren können.

Was mich zur Zeit nervt: Da "optimiere" ich einen Code und nachher dauert die Ausführung 3 x so lange wie vorher. Und ich habe nicht die geringste Ahnung wieso.
Und wenn man ein FPGA programmiert, dauert der Kompiliervorgang eine halbe Ewigkeit (aktuell ca. 12 Minuten). Bis der da endlich seinen Bit-Code erzeugt hat ...

Ich kenne solche Simulatoren! - hatte im Frühjahr auch einen zum Testen!
Das Problem ist nur, dass ich Maschinen programmier mit bis zu 12 Achsen/Spindeln, das muss man dem Simulator erst mal beibringen diese Achsen zu simulieren.

[himitsu]

Ich weiß, man dachte wohl nie, daß sowas jemals aus meinem Mund kommt.

Ich hasse Unicode und nichtfunktionierende Generics.



OK, eigentlich nicht das Unicode selber, sondern eher die Kombination aus Ansi und Unicode, bzw. wenn man Methoden erstellen will, welche "beides" Unterstützen sollen und dabei nicht auf die automatische Stringumwandlung von Delphi zurückreifen sollen.

Auch nicht grundsätzlich die Generics, sondern Generics, welche nicht das machen/können, welches ich mir wünschen würde
und datürlich die damit zusammenhängenden "internal compiler error"s.



Hatte die nichtfunktionierenden Generics wieder ausgebaut, dazu noch PChar eingebaut (sollte für mehr Übersicht und weniger Code sorgen)
und hatte mich nun ein bissl im zu ändernden Code und der Masse an Methoden verlaufen.
(vor 'ner Stunde hab'sch dann aufgegeben, 'ne kleine Pause gemacht und fang nun von vorne an und versuch mit jetzt erstmal 'nen Überblick zu machen)

[Bbommel]

Zitat von himitsu:

OK, eigentlich nicht das Unicode selber, sondern eher die Kombination aus Ansi und Unicode, bzw. wenn man Methoden erstellen will, welche "beides" Unterstützen sollen und dabei nicht auf die automatische Stringumwandlung von Delphi zurückreifen sollen.

Obwohl ich mich über D2009 total gefreut habe und froh war, dass Delphi von Haus aus Unicode kann und ich die TNT-Komponenten loswerden konnte, habe ich in dem Zusammenhang auch einen ganz großen Nerv-Favoriten: TStringList.LoadFromFile, das beim Versuch, eine UTF8 codierte Datei zu öffnen, einfach komplett rumzickt, sobald sich auch nur ein einziges Zeichen eingeschlichen hat, das nicht korrekt codiert ist. Anstatt dieses eine Zeichen dann "falsch" auszugeben, wird direkt die ganze Datei weggeschmissen. Und mein bisheriger (funktionierender) Workaround, alles mit readln zu lesen und dann selber umzuwandeln, macht leider Probleme, wenn man Dateien von einem Samba-Laufwerk liest, weil es dann viel, viel zu langsam ist.

Das wollte ich doch schon immer mal loswerden...

Bis denn
Bommel

[mschaefer]

Moin,

das wenn es mal wieder ein MegaFormular ist ich dem Editor nicht verschieden Hintergrundfarben für verschiedene Programmierabschnitte geben kann...

Grüße // Martin

[himitsu]

Daß der Compiler immernoch nicht mit "vordefinierten" Klassen umgehen kann, das nervt tierisch.

Beispiel:

Delphi-Quellcode:

type 
  TMyClass = class;

  // eventuell weitere Typen

  *  // ein Fehler (hier einfach mal ein ungültiges Zeichen)

  // eventuell weitere Typen

  TMyClass = class
    // irgendwas
  end;

Normaler Weise würde man hier Folgendes erwarten:

Zitat:

[DCC Fehler] ...: E2029 Deklaration erwartet, aber '*' gefunden

aber nein, stattdessen wird die Forward-Declaration bemängelt und man sieht nur Dieses:

Zitat:

[DCC Fehler] ...: E2086 Typ 'TMyClass' ist nicht vollständig definiert

Toll daran ist besonders, daß man den Fehler also nun selber suchen darf ,
welches bei einem größeren Interface nicht immer leicht ist.

[bernau]

Daß man Frames nicht auf Readonly setzen kann.

Ein Frame verwendet man ja in der Regel auf mehreren Formularen. Wenn man "ausversehen" die Position eines Elementes auf einem verwendeten Frame leicht ändert fällt das nicht auf. Wenn ich im Nachhinein die Elemente auf dem ursprüngliche Frame ändern muss um z.B. weitere Elemente hinzufügen muss, dann gehen diese Verschiebungen nicht mehr auf das abgeleitete Frame über. Das sieht dan fürchterlich aus. Muss also erst mal alle Forms anschauen, und sehen, wo das Frame nicht korrekt dargestellt wird.

[stahli]

@Bernau: schließe mich an

@DP: Vielleicht könnte man in der DP ein Unterforum "Wunschliste an Delphi" auf machen und dort gezielt Meinungen zu Verbesserungen zusammentragen (und ggf. bei allgemeiner Zustimmung an Emb. weiterleiten).