Hartnäckiger Fehler
Moderator: Moderatoren
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Hallo, Ewald.
Ich denke, Du kannst den Fehler beseitigen, indem Du jeder editierbaren Spalte ein eigenes Editierfeld zuordnest, wie in meinem vorigen Posting gezeigt. Die Spalten in Deinem Browse sind dreimal vom Datentyp "Character", einmal "Date" und einmal "Numeric". Irgendwas verhaspelt sich da. Vermutlich könntest Du das sogar nachstellen, wenn Du ein bisschen herumdaddelst.
Ich denke, Du kannst den Fehler beseitigen, indem Du jeder editierbaren Spalte ein eigenes Editierfeld zuordnest, wie in meinem vorigen Posting gezeigt. Die Spalten in Deinem Browse sind dreimal vom Datentyp "Character", einmal "Date" und einmal "Numeric". Irgendwas verhaspelt sich da. Vermutlich könntest Du das sogar nachstellen, wenn Du ein bisschen herumdaddelst.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
irgendwie muss ich ihn getreten haben dass er meine Vorschläge so halbherzig runter putztTom hat geschrieben: In diesem Szenario könntest Du das Get-Objekt auch überwachen, aber ich wage zu bezweifeln, dass das von Hubert angeregte "SetTimerEvent" dafür sinnvoll ist,
da der Timer viel zu selten "zuschlägt". Bei einem Überwachungsintervall von einer hundertstel Sekunde können tausende Operationen übersehen werden.
1. hatte ich auch geschrieben, dass ich in einem normalen Programm die Überwachung in die Eventloop einbauen würde, ob das bei Express geht weiß ich aber nicht
2. Es ist sicher nicht optimal zu wenig zu protokollieren, aber das Hauptproblem bei 100 Protokollpunkten pro Sekunde ist eher dass es zu viele sind ( 100 * 60 * 60 = 360.000 )
Wenn es eine dynamische Variable ist, muss die ja irgendwann angelegt werden, diesen code musst du suchen (Express hat doch den Quellcode dabei oder ?) ... oder in der Eventloop auf das Fenster / Control reagieren, das diese enthält.
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Hallo, Hubert.
Es geht nicht um eine dynamische Variable, sondern um die iVar eines Objekts (bzw. mehrere Objekte), auf das Ewald überhaupt keinen direkten Zugriff hat.
Es geht nicht um eine dynamische Variable, sondern um die iVar eines Objekts (bzw. mehrere Objekte), auf das Ewald überhaupt keinen direkten Zugriff hat.
Vor dem Hintergrund, dass Prozessoren im Gigahertz-Bereich getaktet sind, käme die Untersuchung einer Speichervariablen alle hunderstel Sekunden in etwa dem Ansatz gleich, mit Lichtgeschwindigkeit die Autobahn entlangzufahren und einmal pro Stunde nachzuschauen, ob man schon in Hamburg ist.Es ist sicher nicht optimal zu wenig zu protokollieren, aber das Hauptproblem bei 100 Protokollpunkten pro Sekunde ist eher dass es zu viele sind
Herzlich,
Tom
Tom
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Hi Tom,
woher weißt du das ich heute noch von Recklinghausen nach Hamburg und wieder zurück muss ?
woher weißt du das ich heute noch von Recklinghausen nach Hamburg und wieder zurück muss ?
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Ich meinte eine dynamisch Instanzvariable ...Tom hat geschrieben:Es geht nicht um eine dynamische Variable, sondern um die iVar eines Objekts (bzw. mehrere Objekte), auf das Ewald überhaupt keinen direkten Zugriff hat.
aber wenn die intern ist ...
Gruß
Hubert
Hubert
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
@Tom,
ich habe den Beitrag in Rogers Forum jetzt auch gesehen. Konnte wohl auch nicht geklärt werden denke ich mal. Mit der Überwachung sehe ich jetzt auch etwas schwarz, da das GET beim Verlassen der Anwendung zwar aktiv ist, wenn man die Anwendung aber verlässt (in eine andere Anwendung klickt) und irgendwann zurückkehrt aber nicht mehr aktiv ist. Das wirft natürlich wieder einige Fragen auf !!!
Glaub mir, das mit dem Daddeln haben wir endlos versucht wenn es geknallt hat. Aber es ist nieeeeeeeee gelungen, den Fehler zu provozieren.
Ich habe die Arbeitsstation jetzt tauschen lassen und werde mit der getauschten Station weiterfummeln. INI/XPF/XML Dateien verwende ich in diesen Programmen übrigens überhaupt nicht.
Danke an alle für die Tipps
ich habe den Beitrag in Rogers Forum jetzt auch gesehen. Konnte wohl auch nicht geklärt werden denke ich mal. Mit der Überwachung sehe ich jetzt auch etwas schwarz, da das GET beim Verlassen der Anwendung zwar aktiv ist, wenn man die Anwendung aber verlässt (in eine andere Anwendung klickt) und irgendwann zurückkehrt aber nicht mehr aktiv ist. Das wirft natürlich wieder einige Fragen auf !!!
Glaub mir, das mit dem Daddeln haben wir endlos versucht wenn es geknallt hat. Aber es ist nieeeeeeeee gelungen, den Fehler zu provozieren.
Ich habe die Arbeitsstation jetzt tauschen lassen und werde mit der getauschten Station weiterfummeln. INI/XPF/XML Dateien verwende ich in diesen Programmen übrigens überhaupt nicht.
Danke an alle für die Tipps
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Hallo, Ewald.
Ich würde Dir wirklich empfehlen, die GETs wie von mir oben gezeigt zu verwenden, also je Datum/Datentyp unterschiedliche. Damit verschwindet das Problem sehr wahrscheinlich.
Ich würde Dir wirklich empfehlen, die GETs wie von mir oben gezeigt zu verwenden, also je Datum/Datentyp unterschiedliche. Damit verschwindet das Problem sehr wahrscheinlich.
Herzlich,
Tom
Tom
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Hi Tom,
ich habe da mit dem Editor schon umgestellt. Das mit dem POP Up hat nicht funktioniert. Nach dem ersten Adrenalinstoß habe ich sofort nachgeschaut.
Er geht nicht um ::isCalc . Geht aber trotzdem nicht.
ich habe da mit dem Editor schon umgestellt. Das mit dem POP Up hat nicht funktioniert. Nach dem ersten Adrenalinstoß habe ich sofort nachgeschaut.
Er geht nicht um ::isCalc . Geht aber trotzdem nicht.
- User : JEDER
------------------------------------------------------------------------------
ERROR LOG of "E:\MED\hosperfa.exe" Date: 27.03.2014 14:44:38
Xbase++ version : Xbase++ (R) Version 1.90.331
Operating system : Windows 06.01 Build 07601 Service Pack 1
------------------------------------------------------------------------------
oError:args :
-> VALTYPE: U VALUE: NIL
oError:canDefault : N
oError:canRetry : N
oError:canSubstitute: Y
oError:cargo : NIL
oError:description : Parameter has a wrong data type
oError:filename :
oError:genCode : 2
oError:operation : classDescribe
oError:osCode : 0
oError:severity : 2
oError:subCode : 1025
oError:subSystem : BASE
oError:thread : 1
oError:tries : 0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Called from DC_INSPECTOBJECT(1433)
Called from (B)MAIN(131)
Called from _READCLICK(2376)
Called from (B)_POPCLICK(2357)
Called from _POPUPBUTTONACTIVATE(2410)
Called from (B)DC_XBPGET:CREATE(663)
Called from DC_GETLIST:EVENTLOOP(4449)
Called from DC_GETLIST:READGUI(3677)
Called from DC_READGUI(101)
Called from DC_BROWCELLEDIT(9743)
Called from (B)DC_BROWCELLBLOCK(9329)
Called from _PROCESSHOTKEY(5320)
Called from DC_GETLIST:EVENTLOOP(4625)
Called from DC_GETLIST:READGUI(3677)
Called from DC_READGUI(101)
Called from MAIN(149)
Re: Hartnäckiger Fehler
Asche über mein Haupt. Damit kann ich nicht (mehr) dienen.Tom hat geschrieben:Dann gibt es sicher auch ein (kleines) Testprogramm, mit dem sich das anschauen und nachstellen lässt. Her damit!
Vielleich liefert Ewald ja noch den passenden BeweisMagic hat geschrieben:Ich meine wir haben dann eines dieser Programm geändert und später sogar den RAM Speicher des Rechners getauscht. Dann war auch Ruhe.
Gruß,
Magic
Magic
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Hallo, Ewald.
Dieser Code war ins Blaue getippt - ich habe auch gerade festgestellt, dass die "OBJECT"-Klausel bei diesen eingebetteten Gets nicht funktioniert. Aber das Objekt ist der zweite Parameter für den POPUP-Codeblock. Also einfach so:
Aber dieses Popup war ohnehin nur dafür gedacht, dass Du das Objekt untersuchen kannst. In erster Linie ging es mir bei diesem Vorschlag darum, dass Du mit diesen eingebetteten typenbezogenen Gets arbeitest, statt dem Browsesystem die Erzeugung der Eingabefelder zu überlassen.
Dieser Code war ins Blaue getippt - ich habe auch gerade festgestellt, dass die "OBJECT"-Klausel bei diesen eingebetteten Gets nicht funktioniert. Aber das Objekt ist der zweite Parameter für den POPUP-Codeblock. Also einfach so:
Code: Alles auswählen
@ nil,nil DCGET ... POPUP {|x,o|DC_InspectObject(o),..}
Herzlich,
Tom
Tom
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Mojn Tom,
stelle grade fest, das das Forum wohl Beiträge schluckt, wenn zwei auf einmal eingestellt werden. Habe grade was geschrieben, was nicht erschienen ist.
Also, ich habe heute morgen an dem Arbeitsplatz den kpl. Rechner gegen einen neuen tausche lassen. Kurze Zeit später erreichte mich die Nachricht, das es genau den gleichen Fehler gegeben hat. Bin sofort hin und habe das Szenario ein paar Dutzend mal nachgestellt bzw. nachstellen lassen. Ging ohne Probleme. Ein Teufelskreis. Da der User zwischenzeitlich das Büro gewechselt hat sind auch die Verbindungen zum Server als Ursache auszuschließen. Ein Hardwareproblem ist es also definitiv nicht.
Jetzt ändere ich mal den Code mit den Editierfeldern. Dazu noch eine Frage, bevor ich da weiter Mist reinschreibe.
Du sagst:
@ nil,nil DCGET db->name GETID "myget" // OBJECT oMyGet
Ist die Angabe des Feldnamens an dieser Stelle richtig/notwendig/egal ?
ich kenne nur
@ nil,nil DCGET xnil GETID "myget" // OBJECT oMyGet
Gruß
Ewald
stelle grade fest, das das Forum wohl Beiträge schluckt, wenn zwei auf einmal eingestellt werden. Habe grade was geschrieben, was nicht erschienen ist.
Also, ich habe heute morgen an dem Arbeitsplatz den kpl. Rechner gegen einen neuen tausche lassen. Kurze Zeit später erreichte mich die Nachricht, das es genau den gleichen Fehler gegeben hat. Bin sofort hin und habe das Szenario ein paar Dutzend mal nachgestellt bzw. nachstellen lassen. Ging ohne Probleme. Ein Teufelskreis. Da der User zwischenzeitlich das Büro gewechselt hat sind auch die Verbindungen zum Server als Ursache auszuschließen. Ein Hardwareproblem ist es also definitiv nicht.
Jetzt ändere ich mal den Code mit den Editierfeldern. Dazu noch eine Frage, bevor ich da weiter Mist reinschreibe.
Du sagst:
@ nil,nil DCGET db->name GETID "myget" // OBJECT oMyGet
Ist die Angabe des Feldnamens an dieser Stelle richtig/notwendig/egal ?
ich kenne nur
@ nil,nil DCGET xnil GETID "myget" // OBJECT oMyGet
Gruß
Ewald
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Geht m.E. beides.Du sagst:
@ nil,nil DCGET db->name GETID "myget" // OBJECT oMyGet
Ist die Angabe des Feldnamens an dieser Stelle richtig/notwendig/egal ?
ich kenne nur
@ nil,nil DCGET xnil GETID "myget" // OBJECT oMyGet
Herzlich,
Tom
Tom
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2936
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Heureka, ich habe herausgefunden wann es passiert. Es liegt eindeutig an Datumsfeldern. Warum es passiert weiß ich allerdings immer noch nicht.
Hier mal 4 verschiedene Szenarien in einem einfachen Browse die ich wieder und wieder getestet habe. Ich weiß es ist Wochenende, hoffe jedoch, das jemand die Muße hat Folgendes zu lesen und vielleicht weiß, wie man da die Bremse ziehen kann.
Ein Browse mit einem Zeichefeld und einem Datumsfeld greift auf eine Datenbank.
Es passiert - egal ob mit oder ohne Editor
1. Ich aktiviere ein Zeichenfeld zur Eingabe
2. Ich wechsel in ein beliebiges anderes Fenster bzw. Programm
3. ich mache einen Doppellick wieder irgendwo !!! in das erste Fenster
- Das Fenster wird aktiv
- Der Eingabefocus steht in dem vorher markierten Zeichenfeld, alles ist ok -
1. Ich aktiviere ein Datumsfeld zur Eingabe
2. Ich wechsel in ein beliebiges anderes Fenster bzw. Programm
3. ich mache einen Doppelklick wieder irgendwo !!! in das erste Fenster
- das Fenster wird aktiv
- das Programm schmiert mit dem Fehler iscalc ... ab
1. ich aktiviere ein Datumsfeld zur Eingabe
2. Ich wechsel in ein beliebiges anderes Fenster bzw. Programm
3. ich mache einen Doppelklick in das aktivierte Datumsfeld des ersten Fensters
- das Fenster wird aktiv
- das Programm läuft normal weiter.
1. ich aktiviere ein Datumsfeld zur Eingabe
2. Ich wechsel in ein beliebiges anderes Fenster bzw. Programm
3. ich mache einen Einfach Klick irgendwo in das erste Fensters
- das Fenster wird aktiv
- das Datumsfeld verliert den Eingabefocus
- ich mache irgendwo im aktiven Fenster einen Doppelklick und das Feld bekommt den Fokus.
Ich habe das mit einem Array ausprobiert, funktioniert aber auch nicht. Gibt einen anderen Fehler und schmiert auch ab.
Hier mal 4 verschiedene Szenarien in einem einfachen Browse die ich wieder und wieder getestet habe. Ich weiß es ist Wochenende, hoffe jedoch, das jemand die Muße hat Folgendes zu lesen und vielleicht weiß, wie man da die Bremse ziehen kann.
Ein Browse mit einem Zeichefeld und einem Datumsfeld greift auf eine Datenbank.
Es passiert - egal ob mit oder ohne Editor
1. Ich aktiviere ein Zeichenfeld zur Eingabe
2. Ich wechsel in ein beliebiges anderes Fenster bzw. Programm
3. ich mache einen Doppellick wieder irgendwo !!! in das erste Fenster
- Das Fenster wird aktiv
- Der Eingabefocus steht in dem vorher markierten Zeichenfeld, alles ist ok -
1. Ich aktiviere ein Datumsfeld zur Eingabe
2. Ich wechsel in ein beliebiges anderes Fenster bzw. Programm
3. ich mache einen Doppelklick wieder irgendwo !!! in das erste Fenster
- das Fenster wird aktiv
- das Programm schmiert mit dem Fehler iscalc ... ab
1. ich aktiviere ein Datumsfeld zur Eingabe
2. Ich wechsel in ein beliebiges anderes Fenster bzw. Programm
3. ich mache einen Doppelklick in das aktivierte Datumsfeld des ersten Fensters
- das Fenster wird aktiv
- das Programm läuft normal weiter.
1. ich aktiviere ein Datumsfeld zur Eingabe
2. Ich wechsel in ein beliebiges anderes Fenster bzw. Programm
3. ich mache einen Einfach Klick irgendwo in das erste Fensters
- das Fenster wird aktiv
- das Datumsfeld verliert den Eingabefocus
- ich mache irgendwo im aktiven Fenster einen Doppelklick und das Feld bekommt den Fokus.
Ich habe das mit einem Array ausprobiert, funktioniert aber auch nicht. Gibt einen anderen Fehler und schmiert auch ab.
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Also, ich bin jetzt soweit, das ich den Fehler beliebig erzeugen kann. Und zwar in allen Express-Anwendungen mit einem Browse im dem auch Datumsfelder sind. Das es bei meinen Kunden nicht überall zu Abstürzen kommt ist wohl nur der Tatsache geschuldet, das es nicht jeder User ausprobiert hat.
Ich habe da eine Bitte an alle, die eine Express Anwendung mit einem Browse in dem auch Datumsfelder editiert werden geschrieben haben. Es würde mir helfen, wenn ihr mal folgendes ausprobiert.
1. In dem Browserfenster ein Datumsfeld nur zur Eingabe aktivieren.
2. Ein anders Fenster (Dosfenster, Outlook was auch immer) anklicken.
3. Wieder irgendwo in die erste Anwendung mit dem Browserfenster einen Doppelklick machen.
Das führt bei mir immer zum Absturz mit de isCalc Variablen.
Vllt. ist der Bug ja mittlerweile korrigiert und das ist nur noch nicht bei mir angekommen.
Hier wäre mal die Testanwendung, mit der ich rumgefummelt habe und in der der Fehler auch immer auftritt.
Ich habe da eine Bitte an alle, die eine Express Anwendung mit einem Browse in dem auch Datumsfelder editiert werden geschrieben haben. Es würde mir helfen, wenn ihr mal folgendes ausprobiert.
1. In dem Browserfenster ein Datumsfeld nur zur Eingabe aktivieren.
2. Ein anders Fenster (Dosfenster, Outlook was auch immer) anklicken.
3. Wieder irgendwo in die erste Anwendung mit dem Browserfenster einen Doppelklick machen.
Das führt bei mir immer zum Absturz mit de isCalc Variablen.
Vllt. ist der Bug ja mittlerweile korrigiert und das ist nur noch nicht bei mir angekommen.
Hier wäre mal die Testanwendung, mit der ich rumgefummelt habe und in der der Fehler auch immer auftritt.
Code: Alles auswählen
#include "appevent.ch"
#include "dcdialog.ch"
proc main
local getlist:={}
set date to german
fmkdb(getlist)
use testdb excl
go top
@ 0,0 dcbrowse ob1 alias "testdb" size 100,13 fit ;
edit xbeBRW_ItemSelected mode 7 ;
font "10.Lucida Console"
dcbrowsecol field testdb->nummer header "Nummer" width 10 parent ob1 editor "ename"
dcbrowsecol field testdb->lo header "LO" width 10 parent ob1 editor "elo"
dcbrowsecol field testdb->eingabe header "Datum" width 6 parent ob1 editor "edatum"
@ nil,nil dcget xnil getid "ename"
@ nil,nil dcget xnil getid "elo"
@ nil,nil dcget xnil getid "edatum"
@ 15,1 dcpushbutton caption "Ende " size 10,1 ;
action {||dc_readguievent(DCGUI_EXIT_OK,Getlist)}
dcread gui fit
close testdb
return
*----------------------------------
function fmkdb(xlist)
local astruct:={}
if !file("testdb.dbf")
astruct := {;
{ "NUMMER" , "C" , 10 , 0 }, ;
{ "LO" , "C" , 8 , 0 }, ;
{ "EINGABE" , "D" , 8 , 0 } ;
}
DBCREATE("testdb",astruct)
use testdb excl
for xi = 1 to 50
appe blan
next
close testdb
dc_getrefresh(xlist)
endif
return .t.
*----------------------------------------------------
proc appsys
return
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2936
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Hallo Ewald,
dein Testprogramm mit xBase++ 1.90.355 und eXpress++ Build 258 erzeugt keinen Fehler, funktioniert.
dein Testprogramm mit xBase++ 1.90.355 und eXpress++ Build 258 erzeugt keinen Fehler, funktioniert.
Viele Grüße
Wolfgang
Wolfgang
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Hi Wolfgang,
das macht mich ratlos. Bei mir knallt sogar das Browser Beispiel in der Express Demo ab wenn ich das mit einem Datumsfeld versuche.
Wie gesagt, Datumsfeld aktivieren, Fenster verlassen und anschließend irgendwo in das verlassene Fenster einen Doppelklick (nicht in das Datumsfeld!)
http://rstower.no-ip.biz/hdd/image.jpg
das macht mich ratlos. Bei mir knallt sogar das Browser Beispiel in der Express Demo ab wenn ich das mit einem Datumsfeld versuche.
Wie gesagt, Datumsfeld aktivieren, Fenster verlassen und anschließend irgendwo in das verlassene Fenster einen Doppelklick (nicht in das Datumsfeld!)
http://rstower.no-ip.biz/hdd/image.jpg
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Muss ja dann wohl so sein. Aber das kann ja dann nur ein xbase++ Hotfix sein den ich nicht habe.
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2936
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Hallo Ewald,
du benutzt noch 1.90.331 und eXpress 255, vielleicht hat sich auch da eine Menge geändert ?
du benutzt noch 1.90.331 und eXpress 255, vielleicht hat sich auch da eine Menge geändert ?
Viele Grüße
Wolfgang
Wolfgang
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Ich nutze den WAA und habe einige Anpassungen in den Express-Libs. Deswegen bin in beim Wechsel von Versionen sehr vorsichtig. Aber in diesem Fall wollte ich es wissen und habe mir eine Umgebung mit XBASE++ 1.90.355 frisch von Alaska und EXP258 aufgebaut. Dann mein Testprogramm von oben erzeugt und das mit dem Klick in das Datumsfeld ausprobiert. Das Ergebnis
Code: Alles auswählen
------------------------------------------------------------------------------
FEHLERPROTOKOLL von "D:\gui\strunk.EXE" Datum: 30.03.2014 13:58:10
Xbase++ Version : Xbase++ (R) Version 1.90.355
Betriebssystem : Windows 7 06.01 Build 07601 Service Pack 1
------------------------------------------------------------------------------
oError:args :
oError:canDefault : N
oError:canRetry : N
oError:canSubstitute: N
oError:cargo : NIL
oError:description : Parameter hat falschen Typ
oError:filename :
oError:genCode : 2
oError:operation :
oError:osCode : 0
oError:severity : 2
oError:subCode : 2311
oError:subSystem : BASE
oError:thread : 1
oError:tries : 0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von DC_XBPGET:HOME(1578)
Aufgerufen von DC_XBPGET:_ASSIGN(1107)
Aufgerufen von DC_XBPGET:SETDATA(774)
Aufgerufen von DC_GETVALIDATE(8587)
Aufgerufen von _PROCESSHOTKEY(5453)
Aufgerufen von DC_GETLIST:EVENTLOOP(4747)
Aufgerufen von DC_GETLIST:READGUI(3785)
Aufgerufen von DC_READGUI(109)
Aufgerufen von MAIN(27)
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2936
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler
Dann installiere mal auch noch die Hotfixes von Alaska, die habe ich m.E. alle installiert.
Viele Grüße
Wolfgang
Wolfgang
-
- Rekursionen-Architekt
- Beiträge: 475
- Registriert: Sa, 08. Apr 2006 14:07
- Wohnort: Datteln
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Hartnäckiger Fehler [erledigt]
Hallo Wolfgang,
da hakt es dann leider aus. Ich konnte zwar mit meinem Schnellzugang die Testversion laden, aber nicht die Hotfixes dazu. Da habe ich nicht mit gerechnet, das ich eine Testversion lade, in der Jahre alte Updates nicht berücksichtigt sind. Wie ich das sehe fehlen da ca. 30 Stück.
Das geht mir zwar total gegen den Strich, aber ich denke, ich werde dieses Thema ungelöst beerdigen und dem User sagen, das er nicht mehr mit aktiviertem Datumsfeld in eine andere Anwendung klicken soll.
@alle,
Danke für die Tips
Gruß
Ewald
da hakt es dann leider aus. Ich konnte zwar mit meinem Schnellzugang die Testversion laden, aber nicht die Hotfixes dazu. Da habe ich nicht mit gerechnet, das ich eine Testversion lade, in der Jahre alte Updates nicht berücksichtigt sind. Wie ich das sehe fehlen da ca. 30 Stück.
Das geht mir zwar total gegen den Strich, aber ich denke, ich werde dieses Thema ungelöst beerdigen und dem User sagen, das er nicht mehr mit aktiviertem Datumsfeld in eine andere Anwendung klicken soll.
@alle,
Danke für die Tips
Gruß
Ewald