Der BE MonthCalendar hat nun wieder einige neue Features.
So gibt es ein BeforeDayDraw Event, durch welches man nun direkt  das Zeichen verhalten des Controls beeinflussen kann.
Ebenfalls kann man nun auch Wahlweise sich Kalenderwochen anzeigen lassen.

Diese Können entweder über die Culture oder über einen Zu dem deutschen Kalendersystem passend berechnet werden.
Wo hier genau der Unterschied liegt kann man in diesen Positing von mir lesen: Iso Calendar Weeks

Die Testversionen an die Betatester in den nächsten Tagen raus

n letzter Zeit beschäftige ich mich damit, Desginunterstützung für Contorls zu erstellen.
Hierbei gibts z.bsp. die neuen smartTags
s.

Um diese soll es mit aber zunächst mal gar nicht direkt gehen.
Sondern viel mehr um ein Problem dass mich schon immer begleitete aber nun bei den smartTags an Bedeutung gewann.
Fehler im Designer!

Was tun wenn Fehler im Designer auftreten ? Man ist ja in keiner Runtime Umgebung und kann somit ja keine Brakepointssetzen ! oder doch ?

Die Lösung ist einfacher als erwartet. Dazu habe ich über eine NewsGroup einen sehr interessanten Link von Frank Dzaebel bekommen s. u.
Die Lösung um im Designer Debuggen zu können ist folgende:
Man setzt in den Projekteigenschaften des ControlLibrary Projektes unter Debuggen ein extres programm zum Debuggen und zwar Visualstudio selbst.


Der rest ist einfach ,man setzt nun das ControlLibrary Projekt als Startprojekt. Zur Controle damit man nachher sieht dass der Debugger etwas tut setzen wir uns in einen eigenen Designer einen Breakpoint.

Führt man nun das Projekt auf öffnet isch eine neue VisualStudio instanz. Diese hat noch kein Projekt geöffnet und tut nichts. Davon sollte man sich einfach nicht irritieren lassen und einfach das ContorlLibrary Projekt in dieser Instanz wieder öffnen. Wenn man sich nun den Designer für das Control anzeigen lässt springt der Debugger an!



Hier der Link zur Microsoft seite mit der Aneitung zum Debuggen im Designer http://msdn2.microsoft.com/de-de/library/5ytx0z24(VS.80).aspx

Das Problem dass sich die KalenderWochen nach FirstFourDayWeek nicht IsoKonform verhalten wurde mir von Microsoft bestätigt. Ein Datum bei dem man dieses abweichende Verhalten festestellen kann ist z.bsp. der 31. Dezember 2003 (Mittwoch) mit einer mit GetWeekOfYear erhält man 53 , Isokonform wäre es aber die 1. Kalender Woche.

Der 1. Januar (Donnerstag) wäre übrigens  auch mit GetWeekOfYear die 1. KW. Laut Isonorm liegen aber alle Tage einer Woche immer in der gleichen Kalenderwoche deswegen wohl die Abweichungen

s. http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=276185

Dort wird auch ein Workaraound empfohlen den ihr unter : http://blogs.msdn.com/shawnste/archive/2006/01/24/iso-8601-week-of-year-format-in-microsoft-net.aspx finden könnt.

Microsoft denkt nun drüber nach wie man es am geschicktesten implementiert dass man die Kalenderwochen berechnung konfigurierbar IsoKonform gestalten kann

Seit ein paar Tagen beschäftige ich mich mit dem TX TextControl in FoxPro.
Dabei musste ich ein paar wirklich "nervtötende" Bugs hinnehmen.

Z.bsp. ist das Control nicht auf einem FoxPro Pageframe lauffähig.
Wenn das Control z.bsp. auf der 2. Page liegt kommt es unter bestimmten Umständen dazu  dass das Control auf allen pages (Also auch !=2) sichtbar ist. Sozusagen durchscheint.

Auf meine Anfrage zum Support wurde mir bestätigt dass das Problem bei FoxPro / Com liegt und nicht behoben werden kann.

Als Workaraound hilft es das control auszublenden wenn das PageFrame auf dem das Control liegt, nicht sichtbar ist. Auch das ist aber nicht wirklich schön...


Ein weiteres Problem ist, dass das Control sich u.U. nicht so verhält wie man es erwartet. Wir setzen das Control als HTML Editor ein. Prinzipiel funktioniert das auch sehr gut. Funktionalitäten wie Export nach PDF etc ist toll.

Allerdings bekommt man Probleme wenn man folgndes durchführt:

1. Text in dem Control schreiben & Formatieren
2. Text in eine Varibale laden
3. Text von der Variablen in das Control laden
4. Text wieder aus dem Contorl laden in eine Variable laden
   

dann ist der HTML Code von 4. nicht mehr der Code den man bei 2. bekommen hat. Gerade Programme die mit OldVal prüfen ob isch ein Textgeändert haben bekommen dann probleme, da der Text sich ja "immer" ändert.

Auch dieses Problem wurde mir bestätigt und als nicht behebbar deklariert. Der Knackpunkt ist dass das Contorl intern ja ein eigenes Format != HTML hat.
Dies hat zurfolge dass jedes mal wenn man HTML abruft man einen HTML Export auslöst. Dieser muss nicht zwangsläufig das gleiche gernerieren wie das was das Control reinbekommen hat.

Man kann sich nur damit helfen das interne Format Wegzuschreiben, man bekommt da ein doublebyte ByteArray zurück. Dummerweise kann man das nicht in FoxPro "normalen" Memos speichern.
Dafür wird dann eine Base64 encodierung benötigt. Allerdings kann man dann wiederum nicht mehr in MEmos nach inhalten suchen, da Base64 keine Klarschrift mehr ist.


Das Umwandeln in Base64 und zurück sieht in FoxPro so aus:

* Abrufen des Textes im intenren Format als ByteArray
lca = thisform.olecontrol1.saveToMemoryBuffer("",3,.f.)

* Base64 Encodieren
lcBase = STRCONV(lca,13)

*... Code zum speichern & Laden in einem MEmo

*Beim laden DEcodieren wir zunächst das Base64 allerdings ist das ergebnis
* ein STring mit steuerzeichen statt eines BinaryArrays Deswgen dann der Binary aufruf
lcplain = CREATEBINARY(STRCONV(lcbase,14))

* Laden des Textes im internen format
thisform.olecontrol1.text =""
thisform.olecontrol1.loadFromMemory(lcPLain,3,.f.)


Falls jemand Lösungen für das HTML "Veränderungs" Problem kennt würde ich mich über Feedback freuen, auch hätte ich gerne Feedback darüber was ihr kennt was sonst noch so an dem Control Probleme bereiten kann

Das Problem dass der HTML string sich ändert tritt logischerweise auch in .NET auf. Das Problem das das Control afu Pageframes durchscheint nur in FoxPro (über Com).