Das Notes Forum

Domino 9 und frühere Versionen => ND8: Entwicklung => Thema gestartet von: oxyd21 am 13.09.11 - 13:28:34

Titel: Auf Mac debuggen
Beitrag von: oxyd21 am 13.09.11 - 13:28:34
Hallo,

ich hab ne kleine Applikation geschrieben, die unter Windows und Citrix problemlos läuft. Auf den Mac-Installation ist aber irgendwie der Wurm drin. Da keine BS-spezifischen Libs drin sind verstehe ich das Problem nicht so ganz.
Scheinbar gibt es keinen Debugger unter OSX. Muss ich jetzt meinen Code mit ein Haufen Print-Statements vollpflastern um den Fehler zu finden?

VG, Michael
Titel: Re: Auf Mac debuggen
Beitrag von: m3 am 13.09.11 - 13:52:14
Ja.
Oder Du beschreibst mal den Fehler, ev. weiß wer was ;)
Titel: Re: Auf Mac debuggen
Beitrag von: oxyd21 am 13.09.11 - 14:10:01
Ich konnte den Fehler noch nicht näher eingrenzen, da auch kein Fehler produziert wird. Ich baue ein Array auf und übergehe Werte, sofern sie in einer Liste sind. Auf dem Mac ist der Array vollständig, auf den Windows-Maschinen wird er korrekt "gekürzt". Gleiche User, gleicher Server, DBs auf dem Server.  :-:

Titel: Re: Auf Mac debuggen
Beitrag von: marschul am 13.09.11 - 14:29:04
Damit hast Du ja bereits eine Eingrenzung: Das scheint beim "Übergehen" der Arraywerte zu passieren. Was findet da denn für ein Vergleich statt?

Habe zwar konkret zu Arrays nix gefunden, aber in der Designer-Hilfe gibt es ein Dokument "Macintosh platform differences in LotusScript". Ist jetzt nicht soooo naheliegend, aber trifft daraus mglw. irgendetwas zu?

Titel: Re: Auf Mac debuggen
Beitrag von: koehlerbv am 13.09.11 - 14:38:02
Die Umsetzung auf dem Mac ist schon manchmal schräg. Ich habe eine Routine, die aus zwei Datumsangaben ein Datumsarray bildet. Sporadisch gibt es dann solch eine Fehlermeldung (erzeugt mein ErrorHandler):

Zitat
Routine:    GetDateArray (vStartDate: 21.04.2011   vEndDate: 25.04.2011
Error number:     Overflow ( 6)
Line:        29

Und hier ist die passende "line 29":
If vEndDate - vStartDate < 0 Then

Da kann man dann auch nur "Hä?". Und den Mac neu starten - dann geht es wieder wochenlang - bis dem Ding erneut schlecht wird.
Auf Windows-Clients ist diese Meldung noch NIE provoziert worden.

Bernhard
Titel: Re: Auf Mac debuggen
Beitrag von: oxyd21 am 13.09.11 - 14:39:01
Ich hab den Fehler gefunden. Hatte zu dem Thema auch letztens einen Thread.


Code
		Dim range As String

		range = "[" + ndtStartDateTime.Dateonly  + " - " + ndtEndDate.Dateonly  + "]"			
		createDateArray = evaluate(|@TextToTime ( @Explode (| + range +|) )|,doc)

Der Windows Client macht jetzt Werte ala 15.09.2011, der OSX Client macht aus korrekten NotesDateTime-Elementen 15.9.11.

Danke IBM!
Titel: Re: Auf Mac debuggen
Beitrag von: Peter Klett am 13.09.11 - 14:49:51
Ich hab da nicht wirklich Ahnung von, vorallem nicht vom Mac, aber kann da nicht auch eine lokale Einstellung des Betriebssystems über die Darstellung von Datum und Uhrzeit einwirken?

Nur so ne Idee ...
Titel: Re: Auf Mac debuggen
Beitrag von: m3 am 13.09.11 - 14:53:37
Zitat von: Peter Klett am 13.09.11 - 14:49:51
Ich hab da nicht wirklich Ahnung von, vorallem nicht vom Mac, aber kann da nicht auch eine lokale Einstellung des Betriebssystems über die Darstellung von Datum und Uhrzeit einwirken?
+1
Titel: Re: Auf Mac debuggen
Beitrag von: koehlerbv am 13.09.11 - 14:58:23
Wo ist denn das Problem bei "15.9.11"? Das ist doch genauso valide wie 15.09.2011.

Bernhard
Titel: Re: Auf Mac debuggen
Beitrag von: oxyd21 am 13.09.11 - 15:06:33
Wenn ich mit den Werten aus dem Array hier z.B. 15.9.11 ein view.Getallentriesbykey auf einen View mit Werten ala 15.09.2011 mache, habe ich schon ein Problem. 
Titel: Re: Auf Mac debuggen
Beitrag von: Peter Klett am 13.09.11 - 15:09:00
Dann musst Du das vorher entsprechend formatieren, z.B. mit dem Befehl Format, wenn es denn Text sein muss (und in einer Ansicht vermute ich, dass Du das brauchst).

Format (Cdat ("15.9.11"), "dd.mm.yyyy") -> "15.09.2011"

EDIT:

Das ist aber kein Problem, dass Du IBM verdankst, sondern den unterschiedlichen Kulturen. Entweder musst Du mittels einer Weltrevolution dafür sorgen, dass alle das gleiche Format schreiben, oder Du baust (was vermutlich einfacher ist) Deine Anwendungen so, dass Du ein festes Format nutzt. In Lookup-Ansichten (die ja hoffentlich nicht sichtbar sind) kannst Du gut mit 2011-09-15 arbeiten, dann werden die auch als Text richtig nach Datum sortiert.
Titel: Re: Auf Mac debuggen
Beitrag von: oxyd21 am 13.09.11 - 15:41:50
Danke für den Tipp, so lüppts.

PS

Ich denke dein Vorschlag hinkt etwas. Wenn ich zwei korrekt formatierte Werte in eine Funktion stecke, erwarte ich, dass die Rückgabewerte auch gleich sind. Auf Windows klappt's und auf dem Mac klappt's auch, wenn ich die Funktion in einem berechneten Feld verwende. Nur in dieser Methode nicht.

Und weil ich auch kein Revoluzzer bin, verwende ich NotesDateTime-Objekte.
Titel: Re: Auf Mac debuggen
Beitrag von: Peter Klett am 13.09.11 - 16:03:46
Hast Du es schon einmal auf einem englisch oder amerikanisch eingestellten Windows versucht? Da kracht das auch. Also keine Mac-Macke. Gleiches "Problem" mit Zahlen. Habe eine ähnlich hart gedrahtete Routine mit Zahlen auf meinem norwegischen (Windows-)Rechner laufen.

Format (1000, "#,#0.00") auf deutsch -> 1.000,00
Format (1000, "#,#0.00") auf norwegisch -> 1 000,00

(Zum Glück schreibe ich damit nur meine Rechnungen :) )

Da "fehlt" der Punkt, und den kriegst Du ums verrecken nicht da rein. Wehe dem, da hängt Programmlogik dran ...

Dafür gibt es die Ländereinstellungen und rechnende Programme sollten damit tolerant umgehen können. Eine Suche in einer Ansicht kann aber nur Text (soweit ich weiß) und da hilft Dir NotesDateTime nicht. Also musst Du den Text entsprechend aufbereiten.

Ich bin aber froh, dass Du von der Revolution absiehst, wobei man vielleicht doch mal darüber nachdenken könnte ... ?
Titel: Re: Auf Mac debuggen
Beitrag von: m3 am 13.09.11 - 16:22:54
Zitat von: Peter Klett am 13.09.11 - 16:03:46
Hast Du es schon einmal auf einem englisch oder amerikanisch eingestellten Windows versucht? Da kracht das auch. Also keine Mac-Macke. Gleiches "Problem" mit Zahlen. Habe eine ähnlich hart gedrahtete Routine mit Zahlen auf meinem norwegischen (Windows-)Rechner laufen.

Format (1000, "#,#0.00") auf deutsch -> 1.000,00
Format (1000, "#,#0.00") auf norwegisch -> 1 000,00

(Zum Glück schreibe ich damit nur meine Rechnungen :) )

Da "fehlt" der Punkt, und den kriegst Du ums verrecken nicht da rein. Wehe dem, da hängt Programmlogik dran ...
Nicht, dass das IBM jemals passieren würde ...

https://www-304.ibm.com/support/docview.wss?uid=swg21506794
Zitat
Some customers have worked around this issue by setting the server's OS locale to a language that uses commas instead of periods for the thousands separator.
Titel: Re: Auf Mac debuggen
Beitrag von: koehlerbv am 13.09.11 - 16:48:08
Michael, mach dein DateArray doch einfach mit LotusScript und lasse die Krücke mit @Text aus:
http://atnotes.de/index.php/topic,51009.msg327927.html#msg327927

HTH,
Bernhard
Titel: Re: Auf Mac debuggen
Beitrag von: ata am 14.09.11 - 07:24:33
Zitat
Michael, mach dein DateArray doch einfach mit LotusScript und lasse die Krücke mit @Text aus:

... das wäre auch meine Empfehlung, der Mischmasch zieht oftmals einen Rattenschwanz an inkompatiblem nach sich. Ich halte in solchen Fällen NotesDateTime für den richtigen Datentyp - es handelt sich um Datumswerte, also verwende ich sie auch so...

Toni
Titel: Re: Auf Mac debuggen
Beitrag von: oxyd21 am 14.09.11 - 08:38:50
Keine Panik!  :)

Ich habe immer ein mögliche Bruchstelle drin, da ich in einem Dokument ein @Explode(DateRange) mache, dass eine Textliste zurück liefert. Das kommt mir entgegen, da ich alle Werte einzeln in einem View anzeige.

Mein Denkfehler war nun, dass ich davon ausgegangen bin, dass zweimal der (fast) gleiche Code auf einem Gerät auch das gleiche Ergebnis erzeugt. Was aber nicht der Fall ist.

Ich kann die Generierung des Datumsbereichs-Arrays ändern, ich vermute jedoch, dass dies grundsätzlich nichts an der Darstellung des Datums ändert, da es auch so wie bisher von Variant in String umgewandelt werden muss.

VG, Michael
Titel: Re: Auf Mac debuggen
Beitrag von: oxyd21 am 14.09.11 - 12:10:44
Bernhard, du arbeitest mit Datumwerten als Variant. Mein Objekt ist jedoch mit NotesDateTime-Werten bestückt. Diese dann in Variablen vom Typ Variant zu stecken, ändert aber nicht den Datentyp an sich, der hier dann V_PRODOBJ (35) und nicht V_DATE (7) ist. Somit kann ich auch nicht die Vorteile des Datum/Variant-Handlings verwenden.

Wie gehe ich am besten mit den NDT-Werten um? Wenn ich das Array per Loop aufbaue, würde ich jetzt das aktuelle Loop-Datum mit dem EndDatum.Dateonly vergleichen, da Timedifference die Uhrzeit mit beachtet. Aber das ist gefühlt irgendwie schräg.

VG, Michael

Titel: Re: Auf Mac debuggen
Beitrag von: koehlerbv am 14.09.11 - 20:40:52
Michael, Du übersiehst hier etwas: Datums-/Zeitwerte speichert Notes (und nahezu alle anderen Programme) als Fliesskommazahl. Um damit umzugehen, stellt Notes hierfür einen speziellen Variant-Typen zur Verfügung und eine eigene Klasse (deren Sinn sich mir in der Masse der Properties und Methoden nur erschliesst unter der Massgabe "Wir wollen mal zeigen, wie das so OO geht").
Die Notes Date/Time Class brauchst Du nur in Ausnahmefällen (beispielsweise für das Timezone-Handling).

Ergo: Trenne Notes DT als Variant und die DT Class. Und wenn Du Fragen hast - sag an! Schau auch beispielsweise mal hier nach: EntwicklerCamp 2008: Notes und die Zeit (http://www.entwicklercamp.de/konferenz/ent2008.nsf/bc36cf8d512621e0c1256f870073e627/ff894193dc08c946c125737600282262/$FILE/T3S6-Notes%20und%20die%20Zeit.pdf)

HTH,
Bernhard
Titel: Re: Auf Mac debuggen
Beitrag von: oxyd21 am 15.09.11 - 08:01:09
Deine Softsphere-Folien gehören schon länger zu meinen "Standardnachschlagewerken". Mein Problem ist eher, dass ich die Zeitzone benötige, da die Applikation im aller weitesten Sinn ein Veranstaltungskalender ist. Somit bleibt mir nicht anderes übrig, als mich zwischen Pest und Cholera zu entscheiden.

Ziel ist es einen Datumsbereich zu generieren:   25.09.2011 : 26.09.2011 : ...

Variante1:
Evaluate + @Explode(DateRange)  -> Funktioniert mit Peters Format-Tipp bisher ganz gut

Variante2:
Array mit Datumswerten über Loop von Anfangsdatum bis Enddatum (als Abbruchbedingung sehe ich hier nur den Datumsvergleich)

Variante3:
Enddatum und Startzeit zusammmenführen und über Timedifference die Tage errechnen und dann loopen.


Was wäre die beste Variante?

VG, Michael
Titel: Re: Auf Mac debuggen
Beitrag von: koehlerbv am 15.09.11 - 10:51:03
Und wo dealst Du mit TimeZone? In den drei von Dir angegebenen Varianten arbeitest Du (per default) immer mit der TimeZone des ausführenden Users / Servers.

Bernhard
Titel: Re: Auf Mac debuggen
Beitrag von: oxyd21 am 15.09.11 - 11:09:14
Zu Beginn der Aktion werden Anfangswerte (Datum, Zeit, Zeitzone) zu NDT-Werten zusammengefügt.