Fehler aus einem DCBROWSE

Moderator: Moderatoren

Antworten
Ewald
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Sa, 08. Apr 2006 14:07
Wohnort: Datteln
Danksagung erhalten: 3 Mal
Kontaktdaten:

Fehler aus einem DCBROWSE

Beitrag von Ewald »

Hallo,
ich kämpfe mit einem Fehler, der sich leider nicht provozieren läßt und immer wieder auftritt.
Es geht um ein Erfassungsprogramm in dem eine Tabelle zeileweise mit Daten gefüllt wird. Das passiert lokal
auf diversen verschiedenen Erfassungsstationen und funktioniert eigentlich reibungslos. Aber eben nur "eigentlich".

Ab und zu passiert nun folgendes. Der Erfasser bemerkt irgendwann eine Fehler, den er ein paar Zeilen vorher gemacht hat.
Um das zu korregieren klickt er in die entsprechende Zelle und macht seine Änderung. Dieser Klick in die Zelle verursacht nun
in nicht nachvollziebaren Intervallen folgende Fehlermeldung, die soweit ich das sehe besagt, dass ein logischer Wert erwartet
wurde. Eine Eingabe in das angeklickt Feld ist nicht erfolgt. Sie kommt aber auch dann, wenn das Feld, das verlassen wird z.B.
der Name ist und das zu ändernde Feld der Vorname. Da ist nichts mit logischer Rückgabe.

Wenn unmittelbar nach dem Fehler exakt das gleiche gemacht wird, passiert nichts. Der Fehler tritt nicht wieder auf.

Code: Alles auswählen

-----------------------------------------------------------------------------
ERROR LOG of "F:\hosperfa.EXE" Date: 20.10.2010 12:47:29

Xbase++ version     : Xbase++ (R) Version 1.90.331
Operating system    : Windows XP 05.01 Build 02600 Service Pack 3
------------------------------------------------------------------------------
oError:args         :
oError:canDefault   : N
oError:canRetry     : N
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Parameter has a wrong data type
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:
------------------------------------------------------------------------------
Called from DC_XBPGET:SETDATA(602)
Called from DC_GETVALIDATE(6613)
Called from _PROCESSHOTKEY(4132)
Called from DC_GETLIST:EVENTLOOP(3581)
Called from DC_GETLIST:READGUI(2961)
Called from DC_READGUI(202)
Called from MAIN(142)
ich vermute, dass das irgendwie mit dem Feld "Behandlung" zusammenhängt weil es hier ein "valid" gibt.

Code: Alles auswählen

@ 06,01 dcbrowse ob1 alias "hospdb" size 102,30 ;
        edit xbeBRW_ItemSelected action {||ob1:forcestable()} ;
        mode DCGUI_BROWSE_EDITACROSSDOWN_APPEND ;
        font "10.Arial" ;
        when {||!empty(vanfang)}

dcbrowsecol field hospdb->name       header "Nachname"   parent ob1 ;
                                     picture "@!" width 15 font "10.Arial" ;
                                     object fangan

dcbrowsecol field hospdb->vorname    header "Vorname"    parent ob1 ;
                                     picture "@!" width 15 font "10.Arial"

dcbrowsecol field hospdb->geb        header "geboren"    parent ob1 ;
                                     width 6  font "10.Arial"

dcbrowsecol field hospdb->behandlung header "Behandlung" parent ob1 ;
                                     width 6  font "10.Arial" ;
                                     valid {||year(behandlung) = vjahr1}

dcbrowsecol field hospdb->nummer     header "Nummer"     parent ob1 ;
                                     width 08 editprotect {||.t.} ;
                                     font "10.Arial" picture "@R 99-99-999999"

@ 37,01 dcpushbutton caption "Ende " size 10,1 ;
        action {||fsicher(getlist),dc_readguievent(DCGUI_EXIT_OK,Getlist)}

@ 37,12 dcpushbutton caption "Einspielen" size 10,1 ;
        action {||fabuchen(getlist)} 
Hat jemand eine Tip, wie ich das 100%ig unterbinden kann. Die User sind manchmal etwas angesäuert, wenn eine Tabelle mit
100 Namen zerschossen wird :)
Wir haben es echt ausprobiert, in so einer Tabelle mit 100ten von Einträgen wie wild hin und her zu klicken und zu ändern, ohne dass irgendwas pasiert ist.
Und dann erreicht mich der Anruf, das es gekracht hat, als erst ein paar Zeilen erfasst waren.
Die Tabelle ist vorbelegt mit ein paar hundert Leersätzen, in denen nur die Felder "Behandlung" und das Feld "nummer" Daten haben.
Behandlung ist vorbelegt mit dem 1.1. von vorjahr1, liefert also standardmäßig immer .t. und kann nicht verlassen werden, wenn das mit dem Datum
nicht paßt.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Tom »

Auf den ersten Blick: "EDITPROTECT" gibt es in DCBROWSECOLUMNS nicht. Das heißt dort "PROTECT".
Herzlich,
Tom
Ewald
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Sa, 08. Apr 2006 14:07
Wohnort: Datteln
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Ewald »

Hallo Tom,
Schreck lass nach. Ich habe mal nachgeblättert. Editprotect verwende ich in diesem Zusammenhang schon seit Jahren in Dutzenden von Programmen. Wurde nie angemeckert und hat auch das gemacht, was ich erwartet habe. Es verhindert die Eingabe in das Feld.
Ich ändere das sofort durch, aber ob das wohl nur sporadisch den Fehler verurschachen kann ?
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Tom »

Mmh. Ich meine, damit mal Probleme gehabt zu haben.

Ansonsten wäre tatsächlich möglich, dass der Valid-Codeblock Probleme erzeugt, weil dort das Feld ohne Alias referenziert ist. Falls irgendwo eine andere Workarea selektiert wurde, kann das zu Schwierigkeiten führen. Einfacher ist sowieso das hier:

Code: Alles auswählen

VALID {|c|Year(CtoD(c)) = nVergleichsJahr}
(c ist der EditBuffer, und der ist immer ein String, deshalb die Konvertierung)
Herzlich,
Tom
Ewald
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Sa, 08. Apr 2006 14:07
Wohnort: Datteln
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Ewald »

Hallo Tom,
bevor ich mich auf meine Quellcodes stürze - heißt das nicht, das beides geht ?

Code: Alles auswählen

#xcommand DCBROWSECOL                                                       ;
                [DATA <xData>]                                              ;
                .
                .
                [<prot: PROTECT, EDITPROTECT> <bProtect>]                   ;
                [<p: PIXEL>] [_PIXEL <_pixel>]                              ;
     
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Tom »

Ja, das heißt es. Roger hat wohl seit meinen letzten Versuchen (Anno Tobak) die DCDIALOG.CH aktualisiert. Ich vermute auch eher, dass es am VALID liegt (siehe vorletzter Beitrag von mir).
Herzlich,
Tom
Ewald
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Sa, 08. Apr 2006 14:07
Wohnort: Datteln
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Ewald »

Hallo Tom,
ich werde das mal mit dem valid so ändern wie du sagst.
Andere Datenbanken sind nicht auf.
Ich kriege das nur nicht gebacken wie das Feld mit dem valid überhaupt ins Spiel kommen soll.
Wie gesagt ist das richtig vorbelegt und liefert immer .t.
Und dann tritt der Fehler ja auch machmal auf, wenn ich z.B. aktuell aus Zelle "Name"
10 Zeilen höher in Zelle "Vorname" klicke (nur klicke).
Du glaubst ja nicht an Bitdreher oder verbogene Bits - ich bin mir da aber manchmal
nicht mehr so sicher ;-)
Ewald
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Sa, 08. Apr 2006 14:07
Wohnort: Datteln
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Ewald »

Zur Info:
Das will er nicht und knallt wegen falschem data typ ab:

Code: Alles auswählen

VALID {|c|Year(CtoD(c)) = nVergleichsJahr}
das geht.

Code: Alles auswählen

VALID {|c|Year(c) = nVergleichsJahr}
Gruß
Ewald
Ewald
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Sa, 08. Apr 2006 14:07
Wohnort: Datteln
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Ewald »

Hallo zusammen
ich muss dieses Thema noch mal aufgreifen.
@Tom
der Fehler ist nach der Umstellung der Validierung auf deinen Quellcode so nicht mehr in aufgetreten.

Nebenbei habe ich heute aber erfahren, dass es einen anderen Fehler gibt, der beliebig in dieser Tabelle reproduzierbar ist.
Es rumst, wenn das Feld mit dem Behandlungsdatum den Eingabefocus hat (und evtl. auch schon ein gültiger Wert drin steht) und der Anwender ausserhalb der Tabelle irgendwo hin klickt.
  • ------------------------------------------------------------------------------
    ERROR LOG of "E:\MED\_xbase\hosperfa.EXE" Date: 05.11.2010 10:53:36

    ------------------------------------------------------------------------------
    oError:args :
    -> VALTYPE: O CLASS: DC_XbpGet
    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 : year
    oError:osCode : 0
    oError:severity : 2
    oError:subCode : 3
    oError:subSystem : BASE
    oError:thread : 1
    oError:tries : 0
    ------------------------------------------------------------------------------
    CALLSTACK:
    ------------------------------------------------------------------------------
    Called from (B)MAIN(124)
    Called from DC_GETVALIDATE(7819)
    Called from DC_GETLIST:EVENTLOOP(4083)
    Called from DC_GETLIST:READGUI(3387)
    Called from DC_READGUI(83)
    Called from DC_BROWCELLEDIT(9008)
    Called from (B)DC_BROWCELLBLOCK(8606)
    Called from _PROCESSHOTKEY(4908)
    Called from DC_GETLIST:EVENTLOOP(4292)
    Called from DC_GETLIST:READGUI(3387)
    Called from DC_READGUI(83)
    Called from MAIN(143)
Wie kann ich das denn wohl abfangen ?
Gruß
Ewald
Paul
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Mi, 21. Mär 2007 15:22
Wohnort: 1230 Wien

Re: Fehler aus einem DCBROWSE

Beitrag von Paul »

Hallo Ewald,

versuchs mal mit VALID {|c|iif(!empty(c),(Year(c) = nVergleichsJahr),.f.)}
anstelle VALID {|c|Year(c) = nVergleichsJahr}, da es mir scheint als wäre in c kein Wert drin.

Gruss aus wien
Paul
Ewald
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Sa, 08. Apr 2006 14:07
Wohnort: Datteln
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Ewald »

Hallo Paul,
ist die Wetterlage in Wien genau so troslos wie bei mir im Ruhrpott ?
Ich hoffe mal nicht.
Also, das Prüfung auf empty() hilft nicht. Der Fehler bleibt der gleiche.
Bei mir rast schon der Quelltexteditor, da ich dieses seltsame Verhalten mit "valid" auch noch an anderen Stellen gefunden habe.
Irgendwie dürfte der Klick ausserhalb der Anwendung überhaupt nicht von "valid" ausgewertet werden.
Ich vertiefe das mal.
Der Anwender gibt Daten in die Tabelle ein und kommt dabei auf die Idee, schnell mal seine emails zu checken. Also klickt er z.B. auf das Outlookicon. Die Anwendung verschwindet im Hintergrund und nichts Schlimmes passiert. Wird sie wieder angeklickt geht es mit der Erfassung weiter. Das ist anders, wenn das Valid-Feld den Fokus hatte. Egal in welcher Zeile. Dann kommt es zum Absturz.
Gruß
Ewald
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Martin Altmann »

Ewald,
sorry, aber wenn Du wo anders hin klickst, wird der Fokus gewechselt! Es kann nur ein Element den Fokus haben - ergo verliert Dein Eingabefeld den Fokus. Und somit wird der Valid ausgeführt!
Und das ist so korrekt unter Windows.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Ewald
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Sa, 08. Apr 2006 14:07
Wohnort: Datteln
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Ewald »

Hallo Martin,
so weit habe ich nicht gedacht. Das der Fokus in dem Fall auf Outlook geht und meine Aplikation ihn verliert war mir schon klar - aber dass der Eingabefokus innerhalb der Aplikation (sprich im Browse) auch verlorgen geht wenn ich ausserhalb des Fensters klicke - das geht mir zu weit ins Eingemachte.
Nundenn, es bleibt der Fehler ;-)
Ich habe das mal auf ein Sinnlosprogramm zusammengedampft.
Es wäre schön wenn mal jemand diesen 15Zeiler testen könnte - Vielleicht liegt es ja an meinen Versionen.
Einfach mal Feld 1 aktivieren und dann ausserhalb der Aplikation klicken = Bei mir Absturz
Feld 2 aktivieren und ausserhalb der Aplikation klicken = Bei mir ok

PS. Weiss jemand warum ich keine email mehr bekomme, wenn hierzu eine Antwort eingeht ? Habe ich da irgewo irgendwas nicht geändert ?

Danke
Ewald

Code: Alles auswählen

#include "appevent.ch"
#include "dcdialog.ch"
proc main
local getlist:={},aa:={}
for i = 1 to 5
aadd(aa,{"test",space(10)})
next
vb="test"
@ 0,0 dcbrowse ob1 data aa size 10,05 fit ;
      edit xbeBRW_ItemSelected 
dcbrowsecol element 1 header "Feld 1 " parent ob1  width 10 ;
                                       valid {|c|c=m->vb}
dcbrowsecol element 2 header "Feld 2 " parent ob1  width 10 
dcread gui fit enterexit
return 

proc appsys
return
Paul
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Mi, 21. Mär 2007 15:22
Wohnort: 1230 Wien

Re: Fehler aus einem DCBROWSE

Beitrag von Paul »

Hallo Martin,

erstmal zum Wetter in Wien: ungewöhnlich warm heute noch (18 Grad ), aber morgen kühlt es ab.

Ok, aber so geht es:

Das Problem ist, daß das Feld c beim Verlassen kein Characterfeld ist, sondern ein Object.

Hab die Valid-Prüfung in eine function ausgelagert.


Servus Paul
Dateianhänge
brtest.prg
(701 Bytes) 222-mal heruntergeladen
Ewald
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Sa, 08. Apr 2006 14:07
Wohnort: Datteln
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fehler aus einem DCBROWSE

Beitrag von Ewald »

Hallo Paul,
das Auslagern in die Funktion fängt diesen Fehler ab - danke dafür.
Bin aber mal gespannt, ob ich dann nicht wieder da lande, womit ich diesen Beitrag eröffnet habe ;-)
Der anz oben beschriebene Fehler ist seit der Umstellung nicht mehr aufgetreten.
Das genau zu klären braucht evtl. Tage - oder auch nur Minuten. :(
Gruß
Ewald
Antworten