Hartnäckiger Fehler

[Tom]

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.

[brandelh]

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.

irgendwie muss ich ihn getreten haben dass er meine Vorschläge so halbherzig runter putzt

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.

[Tom]

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 ist sicher nicht optimal zu wenig zu protokollieren, aber das Hauptproblem bei 100 Protokollpunkten pro Sekunde ist eher dass es zu viele sind

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.

[Ewald]

Hi Tom,
woher weißt du das ich heute noch von Recklinghausen nach Hamburg und wieder zurück muss ?

[brandelh]

Es geht nicht um eine dynamische Variable, sondern um die iVar eines Objekts (bzw. mehrere Objekte), auf das Ewald überhaupt keinen direkten Zugriff hat.

Ich meinte eine dynamisch Instanzvariable ...

aber wenn die intern ist ...

[Ewald]

@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

[Tom]

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.

[Ewald]

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.

• 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)

[Magic]

Dann gibt es sicher auch ein (kleines) Testprogramm, mit dem sich das anschauen und nachstellen lässt. Her damit!

Asche über mein Haupt. Damit kann ich nicht (mehr) dienen.

Ich meine wir haben dann eines dieser Programm geändert und später sogar den RAM Speicher des Rechners getauscht. Dann war auch Ruhe.

Vielleich liefert Ewald ja noch den passenden Beweis

[Tom]

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:

Code: Alles auswählen

@ nil,nil DCGET ... POPUP {|x,o|DC_InspectObject(o),..}

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.

[Ewald]

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

[Tom]

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

Geht m.E. beides.

[Wolfgang Ciriack]

Ich benutze es auch so, wie du es kennst, mit xNil.

[Ewald]

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.

[Ewald]

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.

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]

Hallo Ewald,
dein Testprogramm mit xBase++ 1.90.355 und eXpress++ Build 258 erzeugt keinen Fehler, funktioniert.

[Ewald]

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

[brandelh]

könnte es eventuell an fehlenden Hotfix liegen ?

[Ewald]

Muss ja dann wohl so sein. Aber das kann ja dann nur ein xbase++ Hotfix sein den ich nicht habe.

[Wolfgang Ciriack]

Hallo Ewald,
du benutzt noch 1.90.331 und eXpress 255, vielleicht hat sich auch da eine Menge geändert ?

[Ewald]

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]

Dann installiere mal auch noch die Hotfixes von Alaska, die habe ich m.E. alle installiert.

[Ewald]

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