Debugger extrem langsam

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Debugger extrem langsam

Beitrag von AUGE_OHR »

Jan hat geschrieben:Das ist mir komplett neu. Ich arbeite schon seit Jahren mit der VX und der Workbench. Und meine xpj heißen nahezu durchgängig einfach nur project.xpj. Der VX ist das vollkommen egal.
anbei meine PROJECT.XPJ und Editor.XPJ was von VX.EXE erstellt wurde.
wie man sehen kann sind die BREAKPOINT und OPENFILES Einträge nur im Editor.XPJ

btw. ich nutze VX.EXE praktisch nur als Debugger und rufe es so auf

Code: Alles auswählen

VX.EXE MyApp.EXE
also nicht über die PROJECT.XPJ Verknüpfung.
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Debugger extrem langsam

Beitrag von ramses »

Hallo

im verlauf dieses Threads wurde über ja über ESXi geschrieben.
Diejenigen welche die Version 6 verwenden sollten umgehend den neusten Patch installieren. Dieser behebt das als kritisch eingestufe Problem "Ausbruch aus der VM"
Gleiches gilt für Workstation 12 und Fusion 8

Gruss Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
Frank Grossheinrich
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 142
Registriert: Fr, 31. Mär 2017 15:06
Wohnort: Eschborn
Hat sich bedankt: 5 Mal
Danksagung erhalten: 81 Mal
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Frank Grossheinrich »

Koverhage hat geschrieben:Rudolf,
O-Ton von Frank Grossheinrich:

Although debugging is for bad programmers only :) .

Wobei die Aussage auch durch das Smiley (in meinen Augen) nicht gemildert wird.
Welche Aussage?

Dass ich in dem ganzen Thread für den Debugger geworben habe,
dass ich versucht haben einen Workbench-Vermeider zu motivieren,
dass ich mihc selbst gemeint habe, ...

... ist wohl entgangen, oder?

Ich möchte nicht zitiert werden und so aus dem Zusammenhang gerissen werden.
Ich bitte höflichst dies zu beachten.

Danke,
O-Ton Frank
We love Xbase++, and you?
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Rudolf »

Hallo,
Betretenes Schweigen...
Also ich hätte mir von Alaska eher einen konstruktiven Beitrag zum Problem gewünscht. Es wird alle betreffen die nicht auf 2.0 umsteigen, und das werden viele sein. Eine Entwicklungsumgebung ohne Debugger ist ein Problem. Habs auch mit VX20 versucht, geht auch nicht.
Grüße
Rudolf
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Jan »

Hallo Rudolf,

ich enthalte mich irgendeines Kommentars zu Franks Posting.

Aber was soll ich sagen? 1.9 SL1 ist 8 Jahre alt. Inzwischen gab es Windows 7, 8, 8.1, 10. Kann man denn wirklich erwarten, das eine so alte Programmiersprachen-Version alles das unterstützt, was sich in der Zwischenzeit so alles im Betriebssystem getan hat? Wobei erschwerend ja noch hinzukommt, das der Debugger unter 10 ja zunächst lief - bis zu jenem Update im vergangenen Jahr, wo selbst die 2.0 nicht mehr mitspielte. Man kann Alaska schwerlich für solche Mätzchen von MS verantwortlich machen. Oder fordern, das die jetzt doch noch einen Fix für die nicht mehr supportete Version herausbringen.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: Debugger extrem langsam

Beitrag von georg »

Guten Morgen,


ich setze immer noch die 1.90.355 ein, wobei alle von Alaska öffentlich bereitgestellten Patches installiert sind. Auch das Windows 10 Pro ist auf dem aktuellen Level.

Wenn ich ein recht grosses Programm im Debugger starte, braucht es von einer Samsung SSD ca. 3 Sekunden, ehe der Debugger bereit ist.

Bei mir ist alles "paletti". Und das gilt für alle Windows-Rechner, auf denen ich hin und wieder programmiere.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Koverhage »

Leider war ich nicht die ganze Zeit in Stuttgart dabei, es wurde aber über den Debugger gesprochen, vielleicht
kann (darf) HaPe was dazu sagen.
Gruß
Klaus
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Rudolf »

Hallo, interessant dass er bei Georg funktioniert. Gerog: Welche Tools verwendest Du ? Welche Windows 10 Version verwendest Du ? Da es mit Win7 funktioniert muss es mit Windows zu tun haben.
Und auch wenn Alaska nicht Schuld ist, wäre vielleicht ein Bugfix bzw. eine Erklärung wieso der nicht mehr läuft ein Zeichen guten Supports.
Grüße
Rudolf
Benutzeravatar
Wolfgang Ciriack
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2932
Registriert: Sa, 24. Sep 2005 9:37
Wohnort: Berlin
Hat sich bedankt: 13 Mal
Danksagung erhalten: 34 Mal
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Wolfgang Ciriack »

Also ich habe mit Windows 10 und VX (1.9) auch keine Probleme beim debuggen.
Viele Grüße
Wolfgang
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Debugger extrem langsam

Beitrag von AUGE_OHR »

bitte schreibt dazu welche VX.EXE Version (Hilfe/About) ihr verwendet, vielleicht sind es unterschiedliche.
wie schon gesagt habe ich normal 2.0.338 unter v1.9.355 keine Problem bei Windows 10/8.1 Pro 64bit oder 10/7 32bit keine Probleme.

nun hab ich hier ein 2-1 Tablet ... und da kam es mir extrem langsam vor ( Win 10 Home 64bit )
gruss by OHR
Jimmy
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Rudolf »

Hallo,
ich verwende dazu noch XB2NET, SQEXPRESS, eXpress++, OT4XB und Chilkat, aber kann mir nicht vorstellen dass eine Lib den Debugger beeinflusst.
Grüße
Rudolf
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: Debugger extrem langsam

Beitrag von HaPe »

Hallo Zusammen !
Leider war ich nicht die ganze Zeit in Stuttgart dabei, es wurde aber über den Debugger gesprochen, vielleicht
kann (darf) HaPe was dazu sagen.
In der 2.0 Build 779 wurden wieder zahleiche Korrekturen/Optimierungen am Debugger vorgenommen.
Am Debugger-Kernel waren es 4 Punkte und 5 Punkte am Workbench Debugger.

Ich bin mir jetzt nicht ganz sicher ob dieser Punkt erst in der 779 hinzu kam, aber die Möglichkeit den Debugger an eine über die Workbench gestartet EXE "zu attachen" finde ich genial.
Man(n) muß keine(n) Breakpoint(s) setzen sondern kann sich in der EXE direkt vor den Problem-Punkt "setzen", dann den Debugger attachen (Ausführen -> An Prozess anhängen ...) und los geht es.

Meiner Meinung nach sind in den letzten 8 Jahren an Xbase++ soviele Optimierungen und Erweiterungen hinzugekommen, dass es wirklich Sinn macht auf die aktuelle Version umzusteigen.

Auch wenn es hier nicht reinpaßt, ein paar Worte von einem langjährigen VFP-Entwickler.
Ich habe bei einer neuen Version immer sofort upgedatet und die Neuerungen zeitnah eingesetzt.
Es waren immer nur kleine Änderungen am Code notwendig; wenn man länger wartet ist der Sprung natürlich viiiel größer.
Es gab sehr viele VFP-Entwickler die mit alten Versionen (älter als 10 Jahre) gearbeitet haben.
Selbst die wirklich moderaten Update-Preise (390,-) haben da nicht geholfen.
Auch wenn es nicht direkt (von $MS) ausgesprochen wurde, der Verzicht vieler Entwickler auf kostenpflichtige Updates waren ein nicht unwesentlicher Grund diese Produkt letztendlich einzustellen. :(
--
Hans-Peter
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Jan »

HaPe hat geschrieben:Hallo Zusammen !Ich bin mir jetzt nicht ganz sicher ob dieser Punkt erst in der 779 hinzu kam, aber die Möglichkeit den Debugger an eine über die Workbench gestartet EXE "zu attachen" finde ich genial.
Man(n) muß keine(n) Breakpoint(s) setzen sondern kann sich in der EXE direkt vor den Problem-Punkt "setzen", dann den Debugger attachen (Ausführen -> An Prozess anhängen ...) und los geht es.
Das gab es schon seit Beginn der 2.0, bereits bei den CTPs. Das ist eine echt super Sache. Leider mit einer ganz doofen Besonderheit (vom Support so bestätigt), aber damit kann man dann schon irgendwie leben.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Debugger extrem langsam

Beitrag von Werner_Bayern »

HaPe hat geschrieben:Ich bin mir jetzt nicht ganz sicher ob dieser Punkt erst in der 779 hinzu kam, aber die Möglichkeit den Debugger an eine über die Workbench gestartet EXE "zu attachen" finde ich genial.
Man(n) muß keine(n) Breakpoint(s) setzen sondern kann sich in der EXE direkt vor den Problem-Punkt "setzen", dann den Debugger attachen (Ausführen -> An Prozess anhängen ...) und los geht es.
Servus Hans Peter,
wusste ich gar nicht. Für was braucht man das?
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Jan »

Hallo Werner,

ich benutze das z. B. um das Programm auf den wahren Daten arbeiten zu lassen. Bei meinem Kunden wird immer automatisch das korrekte Datenverzeichnis gewählt (Entwicklung oder Produktiv). Aus er Entwicklungsumgebung komme ich also nicht auf die produktiven Daten. Wenn ein Fehler aber nur dort auftritt, dann starte ich das Programm in der produktiven Form, starte die Workbench mit dem dazugehörigen Projekt, und verknüpfe mich auf die schon laufende exe. Klappt sehr gut. Nur leider ist die Anzeige der prg im Projekt danach in der Workbench-Instanz nicht mehr vollständig. Ich muß das Projekt also hinterher neu in der Workbench laden. Doof, aber damit kann ich durchaus leben.

Lt. einer sehr frühen Aussage von Steffen, an die er sich später nicht mehr erinnern konnte, sollte das auch mal auf die Ferne gehen. Ich mich also mit dem Debugger auf die exe beim Kunden oder bei Mitabreitern im gleichen Netzwerk aufschalten kann. Ob das dann per Teamviewer oder IP oder sonstwas gehen sollte, weiß ich aber nicht mehr.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: Debugger extrem langsam

Beitrag von HaPe »

Hallo Werner !
aber die Möglichkeit den Debugger an eine über die Workbench gestartet EXE "zu attachen" finde ich genial.
Man(n) muß keine(n) Breakpoint(s) setzen sondern kann sich in der EXE direkt vor den Problem-Punkt "setzen", dann den Debugger attachen (Ausführen -> An Prozess anhängen ...) und los geht es.
wusste ich gar nicht. Für was braucht man das?
Das ist eine einfache Möglichkeit den Debugger einzusetzen ohne vorher Breakpoints im Quellcode zu setzen.
Die EXE muß damit auch nicht im Debug-Modus gestartet und "ausgebremst" erst zum Problem-Punkt gelangen.
Man muß dazu sagen, dass genau der Quellcode aus dem die EXE erstellt wurde, natürlich in der Workbench verfügbar sein muß.

Ich selbst habe dazu bisher noch keine eigene Erfahrung; diese Möglichkeit wurde von Steffen Pirsig am Samstag beim Stuttgarter XUG-Treffen gezeigt. Damit werde ich mich demnächst dann ausgiebiger beschäftigen.
Lt. einer sehr frühen Aussage von Steffen, an die er sich später nicht mehr erinnern konnte, sollte das auch mal auf die Ferne gehen. Ich mich also mit dem Debugger auf die exe beim Kunden oder bei Mitabreitern im gleichen Netzwerk aufschalten kann. Ob das dann per Teamviewer oder IP oder sonstwas gehen sollte, weiß ich aber nicht mehr.
Diese Möglichkeit hat Steffen Pirsig am Samstag beim Stuttgarter XUG-Treffen auch angesproffen.
Technisch "verbindet" sich der Debugger aktuell per "Named Pipes" mit der laufenden EXE. Die Kommunikation über "Named Pipes" läuft nur lokal auf dem selben PC.
Alaska möchte die Kommunikation umstellen auf TCP/IP, wodurch eine Verbindung des Debuggers mit der laufenden EXE auch im Netzwerk möglich wäre. Damit man auch die GUI des Programmes sieht, wird man um eine Remote Desktop-Verbindung, TeamViewer oder ähnliches nicht herum kommen.
Das deckt sich mit der Aussage von Jan weiter oben.
--
Hans-Peter
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Jan »

HaPe hat geschrieben:Technisch "verbindet" sich der Debugger aktuell per "Named Pipes" mit der laufenden EXE. Die Kommunikation über "Named Pipes" läuft nur lokal auf dem selben PC.
Alaska möchte die Kommunikation umstellen auf TCP/IP, wodurch eine Verbindung des Debuggers mit der laufenden EXE auch im Netzwerk möglich wäre. Damit man auch die GUI des Programmes sieht, wird man um eine Remote Desktop-Verbindung, TeamViewer oder ähnliches nicht herum kommen.
Das deckt sich mit der Aussage von Jan weiter oben.
Danke für die Info. Das wäre natürlich ein enormer Schritt, denn dann kann ich mich bei den Mitarbeitern oder Kunden direkt aufklinken, wenn die ein Problem haben. Und muß das nicht erst mühsam bei mir nachstellen.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Debugger extrem langsam

Beitrag von Werner_Bayern »

Servus Jan,

das hört sich ja interessant an. Habs natürlich gleich probiert. Auf die ausserhalb der WB gestartete EXE draufgeschaltet, schwubs, war das vorher dazu geladene Projekt weg. Dachte, ich muss es neu laden, hab also alles schließen angelickt, dann wurde das extern gestartete EXE abgeschossen und die WB hängt.

Nochmal gestartet, nochmal getestet, irgendwann schaltet sich der Debugger bei XbpImageButton ein. Bei den Meldungen in der WB steht, dass der Debugger in der nächsten Zeile mit Debuginformationen angehalten wird. Ok, also, XbpImageButton von Alaska wird mit Debug-Infos ausgeliefert und meine EXE selbstverständlich nicht, daher sehe ich dann auch nichts im Debugger?
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Jan »

Hallo Werner,

öhm ... Bei mir klappte das bislang immer.

Aber ja, Du hast Recht. Das Ding ist in dieser Situation etwas zickig. Aus zwei Gründen:

Wie schon erwähnt wird das zur exe gehörige Projekt in der Workbench ziemlich abgespeckt. Immer nur die prg(s) (ja, ich weiß, prg hat kein Mehrzahl-s, ich wollte das damit nur verdeutlichen), die wirklich in dem Moment benötigt werden. Aber das hat bislang immer sauber bei mir funktioniert.

Aber es gibt einen viel schlimmeren Bug. Den Alaska aber partout nicht einsieht. Es geht darum: Ich arbeite oftmals mit mehreren offenen Projekten. Oder habe ein Projekt offen, und muß nur mal schnell eine andere prg öffnen, um da mal was nachzusehen. Im ersten Fall schließt die Workbench einfach das erste Projekt, um dann das neue zu laden. Im zweiten Fall wird die prg einfach in daqs offene Projekt mit reingeladen (nicht in die xpj, aber in einen Tab des aktuellen Projektes).

Ich möchte einfach gerne auf eine xpj im Explorer klicken, und eine neue Instanz der Workbench geht mit diesem Projekt auf. Eine prg im Explorer anklicken, und eine neue Instanz der Workbench geht mit nur dieser prg auf. Aber Alaska sieht das Problem wie gesagt überhaupt nicht. Und ist nicht gewillt, dieses Verhalten zumindest als Option in die Einstellungen mit aufzunehmen.

Das hat mich echt angek...zt. So kann ich nicht produktiv arbeiten. Ich habe also folgendes gemacht: Ich habe die komplette Registry abgegrast nach xwb.exe, und das durch xppworkbench.exe ersetzt. xwb.exe ist nur ein Loader für die Workbench, bewirkt aber das in meinen Augen vollkommen inakzeptable Verhalten. Rufe ich die xppworkbench.exe direkt auf, bleibt alles genau so offen, wie ich das will. Seit einem der letzten Updates von Alaska bleiben diese Einstellungen auch bestehen, vorher durfte ich das Suchen und ersetzen nach jedem update neu starten.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Debugger extrem langsam

Beitrag von Werner_Bayern »

Servus Hans-Peter,

danke für die Info. Sehe da aktuell keine Notwendigkeit für mich, da es nur lokal geht. Wann arbeitet man schon mit seinen eigenen Apps? Hauptsächlich beim Entwickeln und da läuft sowieso alles über die Workbench. Der Geschwindigkeitsunterschied zwischen WB-Debugmodus und EXE mit Debuginfos extern gestartet ist für mich nicht relevant.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Debugger extrem langsam

Beitrag von Werner_Bayern »

Jan hat geschrieben:Ich möchte einfach gerne auf eine xpj im Explorer klicken, und eine neue Instanz der Workbench geht mit diesem Projekt auf. Eine prg im Explorer anklicken, und eine neue Instanz der Workbench geht mit nur dieser prg auf.
Servus Jan,

das läuft doch inzwischen einwandfrei mit der Anleitung hier im Forum? Ich mache das auch so, funktioniert wunderbar.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Debugger extrem langsam

Beitrag von Werner_Bayern »

Werner_Bayern hat geschrieben:XbpImageButton von Alaska wird mit Debug-Infos ausgeliefert
Darf mich korrigieren: XbpImageButton wird ein einer DLL von mir mit ausgeliefert und dort war versehentlich Debugcode mit drin.
es grüßt

Werner

<when the music is over, turn off the lights!>
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: Debugger extrem langsam

Beitrag von georg »

Hallo,


was verwende ich an Tools?

OT4XB, ansonsten alles nur Xbase++ pur. SQLExpress ist auch drin, aber auch das ist "nur" Xbase++ pur (aus dem Quelltext compiliert).

Auch auf die XBTools greife ich m.W. nicht mehr zu, sondern habe das ersetzt.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
Frank Grossheinrich
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 142
Registriert: Fr, 31. Mär 2017 15:06
Wohnort: Eschborn
Hat sich bedankt: 5 Mal
Danksagung erhalten: 81 Mal
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Frank Grossheinrich »

Rudolf hat geschrieben:Also ich hätte mir von Alaska eher einen konstruktiven Beitrag zum Problem gewünscht. Es wird alle betreffen die nicht auf 2.0 umsteigen, und das werden viele sein. Eine Entwicklungsumgebung ohne Debugger ist ein Problem. Habs auch mit VX20 versucht, geht auch nicht.
Jep.
1) bitte habt Verständnis, dass wir definitiv nicht 2 Froen betreuen. Unsere eigenen Newsgroups wären eine aussichtsreichere Stelle. Und auch hier sind wir schon rar. Aber wenn Zeit erlaubt ...
2) auch auf unserer Newsgroup hätte ich nichts andres gesagt als Jan. Das trifft den Nagel absolut auf den Kopf.
3) SET NACHDENKEN ON
die 1.9 User "erwarten", dass wir Bugs fixen, die Microsoft einegschleppt hat, wollt aber nicht in die Platfform Xbase++ investieren und Updates kaufen? Woher soll das Geld kommen, dass wir diese Fixes machen? Ich verstehe die Logik nicht.
Ich kann (und möchte) das auch nicht diskutieren. Xbase++ 1.9 wird definitiv nicht mehr weitergepflegt. Das ist eine sichere Sache.

Grüße, O-Ton Frank
We love Xbase++, and you?
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Debugger extrem langsam

Beitrag von Koverhage »

Aber wenn Zeit erlaubt ...
Wird auch auf 2 Jahre alte Beiträge geantwortet ;-)
Gruß
Klaus
Antworten