das ist doof. Früher war FloatNum identisch mit long double - also eine 10-Byte-Real-Zahl. Bei Watcom ist long double aber nur 8 Byte - damit es nicht zu unidentifizierbaren Fehlern kommt wurde FloatNum zur Struct - um genau in den den Fällen wie in dem Code oben einen Compilerfehler zu erzeugen.
Jetzt muss man genau verstehen, was die Routine macht - z.B. ob sie funktioniert wenn man statt einer Real-Zahl (FloatNum) eine Ganze Zahl (Integer, Word, oder dword) für today, day und testDay verwendet. Da müsste man schauen, was FloatGetDateNumber wirklich macht (liefert sie eine Ganzzahl oder eine Real [julianisches Datum] und wenn ja, wird das benutzt?). Dann kann man vielleicht FloatFloatToDword oder ähnlich statt FloatPopNumber verwenden. Andernfalls muss man sehen, wie man die Subtraktion mit den Structs löst - das wüsste ich jetzt nicht. Da gibt es irgendwelche Konvertierungsroutinen zwischen den verschiedenen Zahlenformaten.
X:/pcgeos/Appl/Breadbox/Dose/process.goc(815): Error! E1081: Expression must be scalar type X:/pcgeos/Appl/Breadbox/Dose/process.goc(815): Error! E1010: Type mismatch X:/pcgeos/Appl/Breadbox/Dose/process.goc(815): Note! N2003: source conversion type is 'int' X:/pcgeos/Appl/Breadbox/Dose/process.goc(815): Note! N2004: target conversion type is 'struct {...}'
TimerGetDateAndTime(&date); FloatGetDateNumber(date.TDAT_year, (byte)date.TDAT_month, (byte)date.TDAT_day); FloatPopNumber(&today); startDay = today - days[span - 1]; Zeile 815 Was muss hier gemacht werden ?
Der Fehler wird wohl bei FloatPopNumber(&today); liegen. Watcom zeigt (aktuelle, warum auch immer) immer die falsche zeile an (815 heißt: fehle in Zeile 814 - oder war es 816?). Wie ist today definiert?
Nachtrag: um herauszubekommen, welche Zeile wirklich gemeine ist, einfach die Zeile auskommentierern. Wenn der Fehler weg ist, ist es die richtige Zeile
Ich habe festgestellt dass Resedit 6 Deutsch beim FreeGeos keine neue Übersetzungsdatei mit VM und GEO Datei erstellen kann und diese ASCII Sachen , das ganze klappt aber ohne Probleme mit der Version hier auf GeosInfoBase unter Geoworks 2.01 und NDO 3.2a.
Der selbe Fehler entsteht bei Breadbox Ensemble 4.1.3.
Ich habe das Falk gemeldet , er wird das noch untersuchen und meint es wäre ein Speicherproblem.
ich habe derzeit ganz viele Sachen am Laufen. Mit ResEdit müsste ich mich sehr intensiv beschäftigen, deswegen steht es relativ weit unten auf der ToDo Liste. Sorry.
Wenn du später Zeit hast kannst du vielleicht das mit dem Resedit testen , weil bei mir stürtzt das immer ab beim import der ASCII Übersetzungsdatei und beim erstellen einer Übersetzungsdatei per VM und geo Datei , das jedoch unter gleichen Bedingung und gleiche Dateien in der englischen Version alles gut funktioniert.
Das fiel mir beim erstellen der Hilfe auf.
Ich benutze ja seit dem ich ein Problem bei Github hatte nur die englische Version.
Bei der deutschen Resedit fiel mir nun auf dass der ASCII import nicht klappt KR09 oder bleibt hängen manchmal Streife im Bild Absturz , in der englischen Version gehts finde nicht heraus warum ? Habe die Hilfedatei Icon und Resedit soweit fertig.
Habe in der Übersetzungsdatei nichts ungewöhnliches gefunden.
Wo liege eigentlisch Icon und Resedit im Unterordner TOOLS in World ? Wegen der Übersetzungsdatei Icon.
ResEdit muss in TOOLS liegen, wegen dem Übersetzungsprozess. Icon würde ich da auch hinlegen. Wenn es später woanders hin kommt muss man eben die Übersetzungsdatei mit ändern.
Bei mir erscheint beim Bildschirmschoner Last words nur ein schwarzer Schirm , sah aber unter PRIVDATA/LASTWORD.000 nit Hexeditor was von graphics. Ich glaube da sollte eine Grafik erscheinen , tuts aber nicht auch nicht unter BBX4.1.3 und gerade getestet unter Freegeos englische NC.
Ich bin am arbeiten der Übersetzung der fehlenden Treiber und Libraries , Johannes hat mir seine Übersetzungsdateien geschickt.
Nun update ich die mit Resedit mit den letzten Ensemble-LOC , scheint zu klappen da bei ihm alles mit Resource 1 2 3 ....und Chunks 1 2 3 ... ist ; nach dem Update der Übersetzungsdatei sind dir Resourcen und Chunks korrekt.
Fiel mir nun auf dass auch Dateien die auf github sind nur Chunks1 2 3 ... haben , habe die nun auch upgedatet.
Hatte nun ein Batchrun gemacht , wählte hier Force Updating Translationfile , musste dann alle dateien öffnen und wieder speichern.
Nun sind die Dateien soweit fertig. Soll ich dir die mal mailen ehe ich die als PR melde.