Allgemeines zu VX

[brandelh]

Hallo,

arbeitet eigentlich schon jemand produktiv mit VX ?

[Manfred]

Moin Hubert,

ja ich.

[Jan]

Ebenfalls. Hauptsächlich recht zufrieden. Mit dem Debugger fechte ich allerdings noch so manche nervigen Kämpfe aus. Der Rest ist fast ganz gut.

Jan

[brandelh]

Hallo Jan,

ist der Debugger besser oder schlechter als der XppDBG ?

Den benutze ich ...

[Manfred]

Hi Jan,

und welche Kämpfe sind das?

Bei mir ist es so, das bei bestimmten Aktionen (die ich aber noch nicht nachvollziehen konnte) VX irgendwie ins Nirwana verschwindet. Lt. Taskmanager zwar 0% Auslastung, aber es passiert nichts mehr.

Beim Debugger ist es so, das Werte durch Überfahren mit der Maus angezeigt werden, aber Werte, die direkt daneben sind schon nicht mehr unbedingt.

Weiterhin habe ich das Problem, dass der Quelltext Bildschirm über den unteren Rand hinausgeht und das Scrollen dann nicht mehr bis zum Ende zu sehen ist, bis der Bildschirm kleiner gemacht und dann von Hand wieder auf die entsprechende Größe gezogen wurde. Das muß nach jeden Neustart von VX erneut passieren. Das ist aber auch wieder von Hardware zu Hardware verschieden.

Aber es ist ja noch eine Pre Release

[Manfred]

Hi Hubert,

der große Vorteil ist, man kann sofort hin und herspringen zwischen den Quelltexten. Weiterhin sieht man die kompletten Zeilen und, was besonders wichtig für mich war, die Hilfe der Funktionen, die Anzeige der Werte, wenn man mit der Maus drübergeht usw.

Also das Teil geht einer professionellen IDE entgegen. Ich arbeite nur noch damit. Ich habe hier 2 Bildschirme und da ist es richtig schön, auf dem einen den Quelltext und auf dem anderen das Programm in voller Größe zu haben.

Mir fällt noch jede Menge dazu ein.

Man kann sofort daraus kompilieren, Die Fehler werden unten angezeigt und es wird sofort im Text auf den ersten Fehler, oder die erste Ungereimtheit gesprungen. Fehler anklicken und Du bist sofort am Quelltext. Also mir gefällt das Teil echt gut. Auch wenn es nicht mit einer IDE von Borland, oder MS für die Visual Studios zu vergleichen ist.

Aber soll ja mal werden.....

[Jan]

Manfred,

das Hautproblem mit denm Debugger ist: Man kommt da nicht wieder raus. Ich habe mir z. B. das angesehen, was wichtig ist, und möchte jetzt das Programm einfach "normal" weiterlaufen lassen. Ohne ständig irgendwelche Tasten drücken zu müssen um von Zeile zu Zeile oder Prozedur zu Prozedur zu kommen. Geht aber nicht, oder ich habe die undokumentierte Tastenkombination einfach noch nicht gefunden.

Das mit den Tooltips ist ebenfalls ganz gut, aber manchmal nerven die und man wird sie nicht einfach so los. Ich meine jetzt in genau der Zeile loswerden, nicht dauerhaft. Einfach nur ESC oder so hilft leider nix.

Ich hätte auch gerne ein korrektes Autovervollständigen. Also Funktionsnamen werden so korrigiert, wie sie in der Funktion aufgegeben wurden, inkl. Groß/Kleinschreibung.

Beruflich muß ich mit notgedringen Access arbeiten, das kann alle diese Dinge sehr gut. Wenn ich ansonsten Access auch etwas abartig finde. Aber das sind teilweise sehr nützliche Gimmicks.

Ansonsten arbeite ich in meinen Xbase++-Programmen inzwischen auch ausschließlich mit VX. Ich finde es bequemer, übersichtlicher, Funktionen sind schnell gefunden, und all die anderen Punkte die Du ebenfalls angesprochen hast.

Aber um auf Dein Problem zurückzuukommen: Wenn ich mich an meine ersten VX-Versuche erinnere kann man doch eigene Tooltips anlegen? Das wäre doch zumindest ein proktikabler Workarround, bis das so richtig gut läuft.

Jan

[Manfred]

Hi Jan,

Manfred,

das Hautproblem mit denm Debugger ist: Man kommt da nicht wieder raus. Ich habe mir z. B. das angesehen, was wichtig ist, und möchte jetzt das Programm einfach "normal" weiterlaufen lassen. Ohne ständig irgendwelche Tasten drücken zu müssen um von Zeile zu Zeile oder Prozedur zu Prozedur zu kommen. Geht aber nicht, oder ich habe die undokumentierte Tastenkombination einfach noch nicht gefunden.

Hm, das verstehe ich nicht. Hast Du es mal mit F9 versucht? Das Teil arbeitet etwas anders als der XPPDBG. Die Breakpoints lassen sich nicht immer entfernen, da hilft nur das Menue View/DebugWindows/Breakpoints/resetten

Das mit den Tooltips ist ebenfalls ganz gut, aber manchmal nerven die und man wird sie nicht einfach so los. Ich meine jetzt in genau der Zeile loswerden, nicht dauerhaft. Einfach nur ESC oder so hilft leider nix.

Da könntest Du Recht haben....

Ich hätte auch gerne ein korrektes Autovervollständigen. Also Funktionsnamen werden so korrigiert, wie sie in der Funktion aufgegeben wurden, inkl. Groß/Kleinschreibung.

Das ist doch vorhanden!? Bei den eingebauten Funktionen usw,. auf jeden Fall. Bei mir wird immer alles in GroßKleinschrift übernommen von den Originalen, oder was meinst Du?

Aber um auf Dein Problem zurückzuukommen: Wenn ich mich an meine ersten VX-Versuche erinnere kann man doch eigene Tooltips anlegen? Das wäre doch zumindest ein proktikabler Workarround, bis das so richtig gut läuft.

Jan

Ja, das kann man machen, oder war das nur eine Bestätigung?

[Jan]

Manfred,

F9 ist gut! Die habe ich nie versucht, denn wenn ich schon das Programm im Debugger gestratet habe, warum sollte ich dann noch einmal F9 drücken?

Breakpoints entefernen ist ja auch im laufenden Betrieb nicht schwierig. Aber der Debugger wollte eben trotzdem immer weiter von zeile zu Zeile oder Prozedur zu Prozedur laufen, ich kam da einfach nicht raus. Egal ob noch Breakpoits da waren oder nicht. Aber das problem ist ja jetzt auch gelöst.

Und mit dem Autovervollständigen meinte ich meine eigenen Funktionen. Die ich auch in Groß/Kleinschreibung erstelle, von wegen der Lesbarkeit und Übersichtlichkeit bei zusammengesetzten begriffen. Und die werden nicht korrigiert bei der Eingabe der Aufrufe.

Und zu den eigenen Tooltips: Eine Bestätigung zu was? Du hattest Dich beschwert, daß es das nicht gab. Und ich meinte mich zu erinnern das man sich die selber bauen kann.

Jan

[Manfred]

Hi Jan,

neeeeeeee, da hast Du was falsch verstanden. Ich meinte PRG Files, die nicht im Projekt stehen, sondern als obj eingebunden werden. Der Quellcode wird erst hinzugeladen, wenn der Debugger einmal durch das PRG laufen mußte. Ab dann steht alles zur verfügung.

Das soll aber in Zukunft gelöst werden lt. Alaska

PS: Mir fällt gerade noch etwas ein. Du weißt, das es eine Liste der einzelnen Hotkeys für VX gibt? Da steht F9 auch drin.

[brandelh]

Hallo Manfred,

mal ne ganz blöde Frage ...

warum sollte man eigenen Programmcode als OBJ statt als PRG einbinden wollen ?
OBJ sind versionsabhängig und der Quellcode muss doch auf jeden Fall irgendwo gespeichert werden

[Manfred]

Hi Hubert,

ich glaube da hatten wir hier irgendwo schon mal drüber "gesprochen".

Ich meine wenn man eigene Bibs schreibt. Diese werden dann irgendwo zentral abgelegt und können dann jedesmal von anderen Programmen als .obj mit eingebunden werden. Bisher habe ich noch keine bessere Lösung gefunden.

[Jan]

Manfred,

und wo gibt es diese Liste? Her damit!!!

Und um noch was zu den obj zu sagen: ich habe auch ein paar eigene Funktionen, die ich immer wieder mal in diverse Projekte einbinde. Das mache ich dann aber so, daß ich die prg in die entsprechenden Projekte mit einbinde. ich habe nämlich, wie Hubert ganz richtig bemerkt hat, null Bock auf ständig irgendwelche Versionskonflikte. Und das kompilieren dauert auf halbwegs neuen Rechnern ja auch nicht ewig lange. zu Clipper-Zeiten habe ich mir für sowas eigene libs geschrieben, auch weil da teilweise Assembler-Code bei war. Aber heute? Muß ich mir nicht mehr antun!

Jan

[Manfred]

Tirili,

und wo gibt es diese Liste? Her damit!!!

das freut mich aber, dass ich nicht der einzige bin, der die Anleitungen nicht liest. Allerdings bin ich jetzt erstaunt, dass ich wohl der einizge war, der die VX Anleitung gelesen hat.

[brandelh]

Hallo Manfred,

meine eigenen Bibliotheken sind immer im Quelltext, zentral entwickelt in einem eigenen Verzeichnis.
In den Anwendungsverzeichnissen habe ich eine CMD Datei, die immer die neuesten Quellcodes der allgemeinen Routinen nachlädt.
Das funktioniert einwandfrei, bei einer neuen Version einfach neu kompilieren.
Dass auch du OBJ verarbeitest, daran kann ich mich nicht erinnern. Ich dachte schmiterlöw hatte das damals probagiert

[Manfred]

Hi Hubert,

iss egal, alles vergessen.

Wie klappt das mit dem CMD? Bin ein wenig doof jetzt.

[Jan]

Manfred,

nachdem ich die erste VX-Version in Händen hielt (oder unter meinen Tasten malträtierte), habe ich viel damit rumprobiert. Andreas meinte damals, nach einer längeren Abhandlung meinerseits über Probleme und fehlende Eigenschaften, zu mir, das es noch sehr sehr viele undokumentierte Features und Hotkeys gäbe.

Da VX ja inzwischen nicht so ganz wirklich weiterentwickelt wurde habe ich auch nie wieder einen Blick in die Doku geworfen. In der (offensichtlich irrigen) Annahme, das diese ebensowenig weiterentwickelt wurde.

Jan

[brandelh]

Hallo Manfred,

da nach bisherigen Rückmeldungen nur 2 VX einsetzen, ist doch 1 der das Handbuch gelesen hat ein guter Schnitt

Aber ich kann versichern, dass ich die Änderungen von Xpp 1.90 zu 1.82 gelesen habe - und sobald ich etwas Zeit für VX habe, werde ich auch dieses lesen

[Manfred]

Hi Hubert,



naja, das kann ja nicht so lange dauern. Sind nur 56 Seiten...

[brandelh]

Hallo Manfred,

CMD

Meine allgemeine Programmumgebung liegt im Verzeichnis HB_XBASE
Jedes neue Programm wird direkt als Kopie davon neu angelegt ...
z.B. in NEU_PROG.

Nun sind zu dieser Zeit alle Dateien gleich. Es werden neue Dateien angelegt und compiliert ...

Irgendwann ändere ich nun eine der allgemeinen Dateien (allgemeine Funktionen, Klasse etc.) in HB_XBASE ab.

Im Anwendungsverzeichnis liegt eine CMD Datei, die für die allgemeinen Dateinamen einen XCOPY durchführt

xcopy \HB_XBASE\ALLG_FUNK.PRG *.* /R /V ...

nun sind die allgemeinen Dateien wieder auf dem gleichen Stand und beim nächsten compilerlauf wird alles zusammengefügt.

[Manfred]

Aaaach so,

das hatte ich mir im nachhinein schon so gedacht.

Bin ich aber im Moment ganz ehrlich..... gefällt mir so nicht.

Eigentlich sollte es so sein, dass das Projektfile alles weiß und dann entsprechend handelt. Das klappt aber nicht wirklich, bzw. m.E. gar nicht. Wenn ich die Files angebe, dann wird zwar kompiliert, aber entweder werden die obj ins falsche Verzeichnis geschrieben (da wo das PRG steht) oder aber später im falschen Verzeichnis gesucht. Das ist blöde. Deshalb habe ich noch diese Lösung gewählt. Wobei das neukompilieren nach Versionswechsel relativ schnell geht, finde ich.

[brandelh]

Hallo Manfred,

so wie es dir gefällt ist es perfekt.