Ein freundliches Hallo an alle,

seit einiger Zeit verhält sich mein Delphi 4 Compiler etwas Merkwürden. Der schlimmste Effekt ist, dass dynamisch erzeugte StringGrids und Panels nach "Lust und Laune" sichtbar sind. Objekte, die zur Entwicklungszeit erstellt wurden erscheinen immer.

Wenn ich zum Beispiel ein StringGrid zur Laufzeit erzeuge, ein Parent zuweise und es sichtbar schalte, so ist es auch sichtbar. Ändere ich das Programm jedoch an ganz anderer Stelle, kann es vorkommen, dass mein Grid nicht mehr erscheint. Oder doch. Oder nach einer weiteren Änderung. Oder gar nicht.

Andere Effekte sind z.B. dass Änderungen nicht übersetzt werden. Füge ich eine Zeile in mein Programm ein, so wird sie beim Testen übersprungen (Kein blauer Punkt am Rand). Es kommt auch vor, dass ich Parameter ändere und das Programm nach wie vor das Verhalten zeigt, wie zuvor. Erst im Assembler sehe ich dann, dass die Änderung nicht übersetzt wurde. Hier hilft manchmal nur Compiler beenden und neu starten.

Der Compiler ist so eingestellt, dass vor dem Compilieren alle geänderten Units gespeichert werden sollen, doch das geschieht nicht immer. Manchmal fragt der Compiler beim Testen, ob er eine geänderte Unit neu laden soll, oder er öffnet automatisch eine bereits geöffnete Unit nochmals. Das kann recht unterhaltsam sein!

Ich nehme an, das alle Effekte die gleiche Ursache haben, aber da meine Compiler-Version nur wenige Quelldateien enthält, kann ich nur auf Assemblerebene testen und das ist nicht so übersichtlich. In die Objekte komme ich nur auf diese Ebene hinein.

Ich hoffe dass einer von Euch diese Nuß schon einmal geknackt hat und mit einen heißen Tipp geben kann. Vielleicht hilft ja ein Parameter beim Starten des Compilers oder eine Direktive.

Grüße von der sonnigen Nordsee

Peter

Ich hatte früher mal solche Effekte, als ich meine Dateien auf dem Netzwerk hatte, das dummerweise eine andere Uhrzeit hatte als mein PC.

Klingt sehr danach, als hättest du das Projekt kopiert und arbeitest mit der Kopie.
Da kommt der Compiler meistens durcheinander, weil er die Units in den falschen Verzeichnissen sucht.

Normalerweise hilft es, wenn du das Original nicht mehr zugreifbar machst (z.B. zippen oder verschieben).

Wenn eine solche Datei ein zweites Mal geöffnet wurde, geh einfach mal in beiden Versionen auf Datei --> speichern unter. Der Pfad wird zu 99,9% nicht übereinstimmen, sondern es werden zwei unterschiedliche Dateien sein.

Hallo baumina, hallo Peter, hallo Sebastian

Dank Euch für die Antworten!

Baumina, in der Tat habe ich das Projekt auf dem Server. Die Uhrzeit wird aber mit Braunschweig vom Server (Novell) synchronisiert. Der Client synchronisiert sich mit dem Server. Da sollte eigentlich alles im Lot sein.

Peter, Dein Tipp könnte greifen. Ich habe vielleicht von der Komponentenentwicklung noch Pfade eingerichtet, die einfach übernommen wurden, aber für das Projekt habe ich die Quellen und Objekte in den Projektordner kopiert. Das werde ich prüfen und berichten.

Sebastian, auch Einen Tipp werde ich prüfen und Berichten.

Grüße von der noch immer sonnigen Noedsee

Peter

Quelltexte direkt auf einem Server zu bearbeiten würde ich nicht empfehlen. Warum machst du das nicht lokal?
Du kannst ja eine Versionsverwaltung benutzen um die Quelltexte auf dem Server zu verwalten und zu sichern, aber über Freigaben macht normalerweise keinen Sinn.

Bei solch einer Konstruktion wundern mich die beschriebenen Effekte nicht wirklich.

Hey, in dem Verzeichnis Deines Projektes wo die *.dpr liegt sollte es auch eine .dsk geben. Mach mal Delphi zu und lösch die Datei dann. Zumindest die hälfte Deiner Fehler könnten davon kommen.

In anderen Fragen die Du hier in letzter Zeit gestellt hast ging es um Komponenten Entwicklung. Verwendest Du mindestens eine dieser Komponenten in dem Projekt das jetzt Probleme macht? Eventuell saut da eine Komponente im Sspeicher rum und überschreibt die Werte einer anderen. Das kann auch zu lustigen Effekten führen.

Viele Grüße aus Dubai, wo es sachte anfängt Warm zu werden

Hallo Sebastian, hallo Stefan,

Dank Euch für Eure Antworten.

Doch zunächst einen Zwischenbericht: Tatsächlich haben sich in den Suchpfaden einige Karteileichen eingeschlichen, die anscheinend zu zu einigen Problemen geführt haben. Nach dem Entfernen der Pfade sah es zunächst gut aus und die Tabellen eschienen wieder. Leider sind diese Effekte nicht reproduzierbar und nach eingen weiteren Tests waren sie plötzlich wieder weg. Aber vielleicht helfen die neuen Tipps dabei.

Sebastian, deine Aversion gegen einen Server kann ich nicht ganz nachvollziehen, zumal bei mir ein Novell-Server werkelt. Hier werden per Loginskript Laufwerksbuchstaben eingerichtet, die sich wie lokale Laufwerke (für das lokale System) wie interne Platten verhalten sollten. Für die Softwareentwicklung bevorzuge ich UNC-Pfade, die von dem Script unabhängig sind, sich aber auch wie ein Laufwerk verhalten sollten. Diese Konstellation macht für mich durchaus Sinn, denn ich bin damit unabhängig von dem Entwicklungsrechner und kann meine Programme in unterschiedlichen Hardwareumgebungen debuggen.

Stephan, was Du so warm nennst, hier haben wir seit einigen Tagen Sonne und über 20° (schwitz). Sicher können sich durch diese Komponenten Fehler eingeschlichen haben. Hast Du einen Tipp, wie man solche Fehler am besten findet??

Inzwischen hat sich ein neuer Fehler eingeschlichen, gegen den ich noch keine Lösung gefunden habe:
Bei einem Stringgrid, das ich mit zusätzlichen Methoden und Propertys ausgestattet habe, erhalte ich die Fehlermeldung "Unit XXX wurde mit unterschiedlichen Versionen des Stringgrids compiliert". Zuvor hatte ich eine Methode hinzugefügt. Eine Vermutug, dass ich eine DCU aus Versehen an die falsche Stelle kopiert habe, hat sich bisher nicht bestätigt. Wenn ich die Quelldatei öffnen möchte, behauptet er, sie könne nicht geöffnet werden. Ohne Projekt kann ich sie jedoch mit Delphi öffnen.

Nachtrag: In der "*.Dsk" habe ich einen Eintrag mit "[....\ProjectGroup1.bpg]" gefunden. Der Pfad zeigt auf einen ganz anderen Ordner! Diese Datei ist jedoch nicht zu finden! Auch, wenn ich diesen Block herauslösche, wird er wieder eingetragen. Was ist das????

Grüße von der wolkenlosen und warmen Nordsee

Peter

Hallo Peter,

in der .dsk was ändern geht nur wenn das Projekt, zu dem die .dsk gehört, nicht in Delphi offen ist. Besser ist es Delphi zu zumachen, .dsk löschen und ohne Probleme weiter arbeiten.
Die .dsk bedeutet Projekt Desktop. Da speichert die Delphi IDE drinne welche Quelltextdateien im Editor offen sind wenn man das Projekt lädst und wo sich die ganzen Fensterchen befinden sollen.
Verschiebt man dann das Projekt immer mal in ein anderen Verzeichnis und arbeitet dann im neuen Verzeichnis weiter, wundert man sich halt warum sich die Änderungen im Programm nicht bemerkbar machen. In Wirklichkeit ist dann die Datei im alten Verzeichnis bearbeitet und nicht die im neuen.
Speicherlöcher findet man am besten mit entsprechnenden Analyse Tools. MadExcept hat da was drinne. Habe ich aber noch nie verwendet. Komme gerade nicht auf den Namen des Tools das ich immer genommen habe (ist leider nicht mehr installiert).

Angenehm Warm meint mindestens 30°C, um Mittag geht es knapp an 40°C (im Schatten), was aber auch noch angenehm ist solange die Luftfeuchtigkeit nicht deutlich über 50% steigt.

Peter18 hat folgendes geschrieben :

Diese Konstellation macht für mich durchaus Sinn, denn ich bin damit unabhängig von dem Entwicklungsrechner und kann meine Programme in unterschiedlichen Hardwareumgebungen debuggen.

Was du mit einer Versionsverwaltung ganz genauso hast, denn du kannst einfach auf den Zielrechner auschecken. Du hast dann aber eben direkt die Sicherung aller Versionen mit den gemachten Änderungen zum Nachschlagen.

Rein zufällig habe ich da gerade etwas vorbereitet:
www.entwickler-ecke....ewtopic.php?t=115462

Hallo Stefan, hallo Sebastian,

Dank euch nochmals.

"MadExcept" habe ich mir angesehen, aber noch nicht getestet. Scheint das zu bringen, was man dazu braucht. Sobald ein anderes Problem gelöst ist werde ich prüfen, ob dieses Tool hilft. Wenn Dir der andere Name einfällt wär das schön. In der .dsk habe ich auch schon mal manuell Karteileichen beseitigt, aber leider ist nicht alles Klartext. Das aktuelle Problem: beim Öffnen einer Unit sagt er "Die Datei kann nicht geöffnet werden." aber nicht warum. Mit Edit öffnen, umbenennen und Speichern hat einmal funktioniert, aber nun nicht mehr.

Angenehm Warm 30°, (Tropf).

Sebastian, warum soll ich mir noch eine Versionsverwaltung einrichten, wenn es mit den vorhandenen Mitteln auch geht?? Der Server hat eine automatische Datensicherung, ich kann mit verschiedenen Rechnern arbeiten, also warum?

Grüße von der bis auf ein paar Schleierwolken sonnigen Nordsee bei noch angenehmen 23°

Peter

Peter18 hat folgendes geschrieben :

Sebastian, warum soll ich mir noch eine Versionsverwaltung einrichten, wenn es mit den vorhandenen Mitteln auch geht?? Der Server hat eine automatische Datensicherung, ich kann mit verschiedenen Rechnern arbeiten, also warum?

Einmal genau aus solchen Gründen:

Peter18 hat folgendes geschrieben :

Das aktuelle Problem: beim Öffnen einer Unit sagt er "Die Datei kann nicht geöffnet werden." aber nicht warum. Mit Edit öffnen, umbenennen und Speichern hat einmal funktioniert, aber nun nicht mehr.

Solche Probleme wie du sie hast hatte ich mit lokal abgelegten Dateien noch nie.

Und zum Anderen speichert die Versionsverwaltung eben alle Änderungen inkl. entsprechender Kommentare, so dass man später auch nachschauen kann wann man was und warum geändert hat. Das kann ein einfaches Backup nicht bieten.
Aber wenn dir das so reicht, sage ich ja nicht, dass du das machen musst.

Wenn du anders arbeitest als vermutlich 99,9% der Entwickler weltweit, brauchst du dich aber auch nicht wundern, wenn du Probleme hast, die sonst kaum jemand hat.

Hallo Sebastian,

jaenicke hat folgendes geschrieben :

Wenn du anders arbeitest als vermutlich 99,9% der Entwickler weltweit, brauchst du dich aber auch nicht wundern, wenn du Probleme hast, die sonst kaum jemand hat.

Deine Antwort hört sich etwas verschnupft an. Das war keineswegs meine Absicht! Aber ich reagiere nun mal allergisch darauf, wenn mir jemand sagen will, wie ich zu Arbeiten habe, denn Deine Antwort hört sich für mich so an wie „Wenn .du das nicht machst bist du doof“. Zumindest kommt es so bei mir an, doch ich will Dir nicht unterstellen, dass es auch so gemeint war! Hinweise, Tipps, Anregngen u.s.w. sind dagegen sehr willkommen!!!! Daher auch meine Fragen nach der Versionsverwaltung.

Das ich so penetrant nachgefragt habe lag daran, dass Du vielleicht eine Reihe von Vorzügen schilderst, die eine solche Software bietet. Aber noch mal: Für mich ist sie im Augenblick nicht sinnvoll!

Eine Versionsverwaltung mag sinnvoll sein, wenn man ein Projekt im "Topdown-" oder "Buttonup-Verfahren" entwickelt und vielleicht mit mehreren Entwicklern daran arbeitet.

Ich jedoch probiere aus! Die Unterlagen zu meinem Compiler sind sehr mager und ich bewege mich bei meinen Tests nicht auf ausgetretenen Pfaden, sondern versuche Ideen mit Delphi umzusetzen und Möglichkeiten und Grenzen auszuloten. Bei solchen Experimenten macht man nun mal Fehler! Aber Fehler sind dazu da, aus ihnen zu lernen! Dabei stoße ich vielleicht auch auf Extremfälle, aber sie kann ich dann später in einem Projekt vermeiden! Ich glaube kaum, dass wirklich 99,9% der Entwickler weltweit mit einer Versionsverwaltung arbeiten, aber egal, zur Zeit kommt sie für mich nicht in Frage!

Nun zu dem geschilderten Fehler:
Leider hat es etwas bis zu meiner Antwort gedauert da andere Aufgaben und die Suche nch der Ursache auf Assemblerebene Zeit beansprucht haben. Dank der Hinweise, die ich erhalten habe, konnte ich folgendes feststellen:
In einer frühen Phase der Erkundung von Delphi habe ich ein Objekt von TStringGrid abgeleitet.


Dabei habe ich "Parent" als Property neu definiert und in in WriteParent auf "inherited Parent" zugegriffen.


Dadurch sind anscheinend beim Optimieren oder Linken Fehler entstanden, die sich in der geschilderten Weise ausgewirkt haben. Es sind dadurch anscheinend auch weitere Seltsamkeiten aufgetreten, die sich z.B. in der Darstellung der Spalten bemerkbar machten. So waren mit


alle Dsten da, es wurden jedoch nur 5 Spalten angezeigt.


Zeigte alle Spalten aber nur 5 wurden mit Daten gefüllt.

Mit


ist aber wieder alles in Ordnung. Anscheinend ist der Compiler dadurch beim Debugen auch ins Schleudern geraten und es sind so weitere Effekte zustande gekommen. Man muß eben etwas genauer hinsehen, was man aus der Zeiten der ersten Gehversuche übernimmt!!!

Grüße von der Nordsee sonnigen und wasmen Nordsee

Peter

Ich wollte dir damit nicht sagen, dass du so arbeiten musst. Und ich bin auch nicht verschnupft. Ich sage nur wie die Mehrheit arbeitet und damit auch gute Erfolge hat, um die Standardlösungen zu zeigen, Denn meistens haben diese Standards auch gute Vorteile gegenüber selbst gebastelten Lösungen.

Wenn du dich dafür entscheidest, anders zu arbeiten als es gedacht oder normal ist, dann passieren gegebenenfalls eben Dinge, die anderen nicht passieren.

Normalerweise fassen die meisten heiße Töpfe auch nur mit Topflappen an. Trotzdem kann man die natürlich auch weglassen. Nur verbrennt man sich dann gegebenenfalls eben die Finger.

Hallo Sebastian,

weil Du keine heißen Töpfe anfassen willst, werde ich mir keine Versionsverwaltung zulegen. (Noch ein Spruch)

Nein, Sprüche helfen nicht! Du hast bisher keine Argumente geliefert, die eine Versionsverwaltung beim Probieren und Grenzen Austesten nützlich erscheinen lassen. Wie gesagt, bei größeren Projekten vor allem, wenn mehrere Entwickler beteiligt sind, ist sie sicher nützlich.

Grüße von der sonnigen Nordsee

Peter

Peter18 hat folgendes geschrieben :

Du hast bisher keine Argumente geliefert, die eine Versionsverwaltung beim Probieren und Grenzen Austesten nützlich erscheinen lassen.

• Du siehst welche Änderungen du gemacht hast, wenn z.B. plötzlich etwas nicht mehr funktioniert
  
• Du siehst beim Abschicken der Änderungen, ob du unbeabsichtigte Änderungen drin hast (z.B. Debugausgaben, ...)
  
• Du hast alle Dateien an genau einer definierten Stelle und brauchst nicht (wie es leider viele ohne Versionsverwaltung machen) Kopien anlegen, die dann evtl. aus Versehen benutzt werden usw.
  Kopien, bei denen man dann wiederum nicht weiß was da eigentlich mittlerweile geändert wurde. Dann kehrt man zu einer Version zurück, nur um zu bemerken, dass eine andere Änderung weg ist, ...
  
• Du arbeitest lokal ohne Netzwerk und damit unter anderem schneller
  
• Du kannst mehrere Entwicklungen parallel machen, zwischen beiden hin- und herschalten und am Ende beide zusammenführen
  
• Du kannst einfach zu einer älteren Version zurückgehen und testen, ob ein Fehler dort schon drin war oder ob etwas dort anders funktioniert hat
  
• Wo du von Probieren sprichst:
  Du kannst jederzeit im Quelltext etwas komplett ändern oder auch löschen um z.B. einen Fehler zu finden, da du die Version ja jederzeit wiederherstellen kannst

Peter18 hat folgendes geschrieben :

Wie gesagt, bei größeren Projekten vor allem, wenn mehrere Entwickler beteiligt sind, ist sie sicher nützlich.

Nützlich sind sie immer, bei größeren Projekten mit mehreren Entwicklern sind Versionskontrollsysteme notwendig, nicht nur nützlich.

Aber wie ich schon sagte:
Es zwingt dich ja niemand dir das Leben leichter zu machen oder irgendetwas zu ändern. Das sind ja alles nur Vorschläge.

Trotzdem bleibe ich bei meiner Meinung, dass einige der im Forum von dir beschriebenen Probleme durch deine Arbeitsweise verursacht werden. Aber das ist meine persönliche Meinung.

Hallo Sebastian,

Dank Dir. Das hört sich ja schon etwas anders an und sieht so aus, als könnnte man damit einiges anfangen, auch beim Herumprobieren.

Aber leider ist das auch eine Preisfrage. Gibt es denn auch Versionsverwaltung zum Null-Tarif zum ausprobieren??

Grüße von der verregneten Nordsee

Peter

Peter18 hat folgendes geschrieben :

Aber leider ist das auch eine Preisfrage. Gibt es denn auch Versionsverwaltung zum Null-Tarif zum ausprobieren??

Andersrum. Mir fällt spontan keine Versionsverwaltung ein, die Geld kosten würde
Aktuell ist wohl git state of the art. Damit würde ich Dir empfehlen zu starten.

Klar! Ist ja von Entwicklern für Entwickler.

Ich verwende zwar kein Git, weis also nicht wie es da aussieht. Aber für SVN gibt es Freeware Programme. Tortoise SVN nutze ich als Client und Visual SVN als Server. Letzteres gibt es auch für Geld, der Mehrwert hält sich für private Anwender aber derart in Grenzen dass es sich einfach nicht lohnt.

Hier habe ich eine kleine Anleitung für Git gemacht, allerdings fehlt noch die Anleitung für einen Server im Netzwerk:
www.entwickler-ecke....ewtopic.php?t=115462

Und hier ist die vollständige Einrichtung mit SVN beschrieben:
www.entwickler-ecke....ewtopic.php?p=683811
Dort ist auch der Server beschrieben und SVN ist auch erst einmal einfacher. Damit kann man zwar weniger machen, aber ich glaube für deine Zwecke sollte es reichen und am einfachsten sein. Du brauchst für die Anleitung aber einen Windows-Rechner als Server, es gibt aber (wie für Git) auch Server für andere Systeme.