 ActiveX
Steuerlelemente
|
 |
Fehlerbehebungen
|
| Steuerelement |
Fehlerbehebung |
| VW4Trend.ocx |
- Beim Marker wurde nach Verschieben bei
Überdeckung durch ein anderes Fenster
die Markerlinie an der falschen Stelle
(an der, wo der Trend in den Offline Modus
geschaltet wurde) gezeichnet.
- Beim Umschalten von Online = false auf
Online = true wurde kein TrendDisplayChanged
Event ausgelöst.
- Die Methode GetValueCoordinates hat keine
XPosition zurückgeliefert, wenn an der
Stelle keine Kurve war. Jetzt wird die
korrekte X-Position und für Y eine -1
geliefert.
|
| VWSTextBox .ocx |
- Beim Neu-Instanzieren war Enabled = False;
Enabled wird nicht gespeichert.
|
| VWSFrame.ocx |
- Endlosschleife beim Setzen des Fokus,
wenn ein Formular mit VWSFrame-Controls
und anderen Controls geladen wird, die
keinen Fokus empfangen können.
|
| VisiWinStudio.ocx
|
- VWSKey:
Der Font wurde nicht mit dem Font aus
der Fontklasse initialisiert, wenn die
Applikation nicht mit der Entwicklersprache
gestartet wurde.
- VWSKey:
Wurde die Visible Eigenschaft des Steuerelementes
zur Laufzeit auf true gesetzt, so erhielt
das Steuerelement automatisch den Focus
und aktivierte das Formular.
|
| VisiWinStudio2.ocx |
- VWSMove:
Wurde die Visible Eigenschaft des Steuerelementes
zur Laufzeit auf true gesetzt, so erhielt
das Steuerelement automatisch den Focus
und aktivierte das Formular.
|
| VWSAlarm.ocx |
- VWSAlarmList:
Wurde die Visible Eigenschaft des Steuerelementes
zur Laufzeit auf true gesetzt, so erhielt
das Steuerelement automatisch den Focus
und aktivierte das Formular.
|
| VWSTouch.ocx |
- VWSScrollBar, VWSCheckBox, VWSOptionButton,
VWSGrid:
Wurde die Visible Eigenschaft des Steuerelementes
zur Laufzeit auf true gesetzt, so erhielt
das Steuerelement automatisch den Focus
und aktivierte das Formular.
- VWSGrid:
Ein im Ereignis GridItemMouseUp geöffnetes
Fenster konnte nicht bedient werden, da
das Steuerelement das Mausereignis nicht
freigegeben hat.
|
| |
|
VisiWinEngine
|
|
| Fehlerbehebungen
|
Rezeptserver
VWRecipeServer.DLL |
- Kleiner Speicherfresser beim Abspeichern
von Rezepten (pro Rezeptvariable ca. 100
Byte)
|
Trendserver
VWTrendServer.DLL |
- Bei Anpassungen für VisiWinNET war die
Möglichkeit verloren gegangen, mit Angabe
eines leeren Dateinamens bei einigen Funktionen
das aktuelle Archiv anzusprechen
- Wenn "AddArchiveNote" oder "StoreUserEntry"
schon aufgerufen wurde, bevor durch die
Abspeicherung eines Samples die Datei
erzeugt wurde, gab es immer einen Fehler
beim Öffnen. Nun können diese Funktionen
die Datei ebenfalls erzeugen.
- Die Dateigrößenüberwachung ermittelte
seit der V4.05 beim Hochfahren nicht mehr
die vorhandenen Archivdateien und berücksichtigte
nur die neu erzeugten Dateien
- Bei Ringpufferarchive wurden nach einem
Seitenwechsel keine alten Daten angezeigt,
sondern nur die neuen.
- Bei "GetFilePath"- und "GetCurrentFile"-Aufrufen
für speicherbasierte Trends (RAM), wird
nun keine Fehlermeldung, sondern ein ""
(Leerstring) zurückgegeben (sonst Fehlermeldung
in VisiWinStudio-Ereignisanzeige: HRESULT
0x1 bei Aufruf GetFilePath)
- Die Funktion "ReadUserEntry" lieferte
nicht den DefaultValue zurück, wenn der
entsprechende Eintrag nicht da war
- Trendcache funktionierte bei Ringpufferarchiven
nicht richtig
|
Alarmverwaltung
VWAlarmServer.DLL |
- GetAlarmData + GetFileNotes + GetAlarmNotes
+ EnumFiles sind jetzt nicht mehr mit
den anderen Alarmfunktionen verriegelt,
damit bei einem längeren Durchsuchen historischer
Dateien nicht die ganze Alarmverwaltung
angehalten wird
|
Audit-Trail
VWLogServer.DLL |
- GetLogData + GetLogFileNotes + GetLogNotes
+ EnumLogFiles sind jetzt nicht mehr mit
den anderen Logfunktionen verriegelt,
damit bei einem längeren Durchsuchen historischer
Dateien nicht das ganze Logbuch angehalten
wird
|
Sprach- und Textverwaltung
(VWTextServer.DLL |
- Speicherleck im Microsoft-Ole-DB-Provider
beim Auslesen von Texten umgangen
|
VisiWinKern
VWEOpc.DLL |
- Ein Schreibauftrag (aus z.B.: SetRecipeValues)
mit 0! Items zu einem ungünstigen Zeitpunkt
konnte das Einlesen der Variablen stören
(in der Diagnose: mehrmals "Variablenänderung
verworfen (wegen anstehendem Schreibauftrag)",
wenn für diese Variable die Variablenverfolgung
eingeschaltet ist)
- "ValidateItems" aus dem OPC-Server-Interface
des Kernels lieferte bei Strukturmitgliedern
(<..> - Zugriff) den Datentyp der Struktur
und nicht des Mitgliedes zurück
- 1 x Lesen oder 1 x Schreiben aus Bitsetzen
durch VWSet für die Steuervariable einer
Gruppe mit Steuervariable führt zum Stillstand
des Kernels, wenn die Items der Gruppe
aus einem OPC-Server sind. Wenn die Items
aus einem VW32-Treibers sind, funktionierte
es nicht.
- In einem seltenen, zeitlich ungünstigem
Fall kann das Setzen des 1xLesen Bits
in der Steuervariablen einer manuellen
Gruppe, die Items eines VW32Treibers enthält,
dazu führen, dass sich der Kernel verhakt
und in der Applikation die Fehlermeldung
"VWEManager wurde wegen Fehlern getrennt"
auftritt
- Das System konnte hängen bleiben, wenn
in einem VW32-Treiber der Datentyp VT_BIT
verwendet wurde und gleichzeitig bei den
"erweiterten Eigenschaften" der Ersatzwertmodus
angeschaltet und die Option "An den Quell-OPC-Server
senden" aktiviert war.
- Wenn man einen Teilnehmer aus einer Struktur
aus VB beschrieben hatte, bekamen alle
anderen Teilnehmer auch einen ChangeEvent
nach VB, das wurde jetzt verbessert.
- Strukturmitglieder waren mit Quality "BAD"
vorbesetzt, alle anderen Items mit Quality
"GOOD". Jetzt sind alle vor dem ersten
Einlesen "GOOD".
- Wenn bei VW32-Treibern 2 Bytes in einer
Struktur in einem Wort definiert sind
und zuerst das Highbyte, danach das Lowbyte
direkt hintereinander (z.B. mit VWSet)
beschrieben werden, konnte es vorkommen,
das der Lowbyte Schreibauftrag das Highbyte
mit dem alten Wert wieder überschreibt.
|
| |
|
|
|
|
|
