WKL Forms Object Library

ActiveX-Steuerelemente für Formulare in Microsoft Access, gebaut auf .NET 10: Strukturen, Datenblätter, ein Gantt-Diagramm, Layout, Navigation, Schaltflächen, Statusanzeigen, Validierung und Benachrichtigungen. Sie fügen sich in Access ein, als gehörten sie dazu: frühe Bindung mit IntelliSense, Einstellungen im Eigenschaftenblatt und in einem Designerfenster, Ereignisse im Formularmodul, feste Fehlernummern und Betrieb in ACCDB, ACCDE und Access Runtime. Diese Dokumentation richtet sich an Access- und VBA-Entwickler, die die Steuerelemente auf Formularen einsetzen, und an Administratoren, die sie auf den PCs der Benutzer einer Anwendung installieren. Aktuelles Release: 2.0.0 – die Änderungen jedes Release stehen in der Datei CHANGELOG.md des Release-Pakets. Bis Release 1.68.2 hieß die Bibliothek WKL Access Components.

Die Steuerelemente, die Access in der Entwurfsansicht anbietet (Textfeld, Kombinations- und Listenfeld, Unterformular, Registersteuerelement, Schaltfläche und ähnliche), genügen für die klassische Datenerfassung. Es fehlt aber vieles, was Benutzer heute von Geschäftssoftware erwarten: eine an eine Tabelle gebundene Struktur, ein Datenblatt, das wie ein modernes Raster gruppiert, filtert und summiert, ein Gantt-Diagramm, eine Navigationsleiste, angedockte Bereiche, die der Fenstergröße folgen, Status-Chips, Benachrichtigungen (Toasts). Access-Entwickler schließen die Lücke mit Behelfslösungen – verschachtelte Unterformulare, Endlosformulare mit bedingter Formatierung, das ungebundene Microsoft-TreeView der Common Controls, das per VBA befüllt wird. Solche Lösungen kosten in jeder Anwendung eigenen Code und sehen trotzdem anders aus als der Rest von Office – und verhalten sich auch anders.

Komponentensammlungen wie DevExpress WinForms oder Telerik UI for WinForms lösen das für .NET-Anwendungen mit Windows-Forms-Steuerelementen. Ein Access-Formular nimmt aber nur ActiveX-Steuerelemente auf; diese Sammlungen lassen sich dort also nicht einsetzen. Die WKL Forms Object Library bringt vergleichbare Fähigkeiten als ActiveX-Steuerelemente nach Access, die den Konventionen von Access folgen: RecordSource, LinkMasterFields, Requery, das Eigenschaftenblatt, Ereignisse im Formularmodul, ACCDE und die Runtime.

Was die Komponenten nicht leisten: Sie ersetzen nicht die Access-Steuerelemente für einfache Eingabefelder, sie arbeiten in Access-Berichten nicht als Listen (eine Liste zeigt dort einen Hinweis), und sie sind keine Windows-Forms-Steuerelemente für .NET-Anwendungen.

• Freigegebenes Paket installieren – Voraussetzungen, Bitversion, Registrierung
• Anwendung auf Release 2.0 umstellen – für Anwendungen, die gegen Release 1.x gebaut wurden
• Designer eines Steuerelements öffnen
• Eine Verwaltungsanwendung bauen – mehrere Steuerelemente im Zusammenspiel: ein Rahmen mit Navigation und Seiten sowie eine Liste mit angedocktem Bearbeitungsformular, das Eingaben prüft (Tutorial des WKL Administration Shell Templates)
• Eine Struktur an eine Tabelle binden und Kundenraster mit Bestellungen erstellen – jeweils ein Steuerelement für sich

• WKL-Steuerelemente per Code in Formulare einfügen
• Ereignisprozeduren für ein Steuerelement anlegen
• Fehler von WKL-Steuerelementen in VBA behandeln
• Sprache der Komponenten festlegen
• Anwendung lokalisieren
• Farben des Datenbankdesigns übernehmen
• Access-Anwendung aus ihren Textquellen bauen

Aufgaben zu einem einzelnen Steuerelement finden Sie in dessen Überblick (siehe Wichtige Funktionen).

Die Steuerelemente platzieren Sie auf Access-Formularen (oder UserForms); die mit (Objekt) gekennzeichneten Komponenten erzeugen Sie in VBA, sie haben kein eigenes Fenster.

Datensätze aus Tabellen und Abfragen anzeigen und bearbeiten.

Einzelne Werte auf einem Formular, gebunden wie ein Access-Steuerelement.

Bereiche eines Formulars anordnen, teilen und ein- oder ausklappen.

Durch eine Anwendung navigieren und ihre Befehle ausführen.

Dem Benutzer Zustände, Zahlen und Ergebnisse zeigen.

Barcodes, QR-Codes und Bilder auf Formularen und in Berichten.

Die Anwendung als Ganzes und ihre Datenquellen.

FindNodes, JPath-Filter und AsJSON nutzen die JSON-Engine von WKL Office JSON, die im Release-Paket enthalten ist. Für einen schnellen Einstieg enthält das Paket außerdem eine Vorlage für den Anwendungsrahmen mit Navigationsleiste, Seite im Unterformular und Befehlsleiste (unter templates\app-shell).

Drei Wege, ein Steuerelement zu konfigurieren. Das Eigenschaftenblatt (Registerkarte Andere), das Designerfenster des Steuerelements (Designer eines Steuerelements öffnen) und VBA über die Eigenschaft Object des Steuerelements (Me!Tree1.Object.RecordSource = …). Alle drei setzen dieselben Eigenschaften, die Access mit dem Formular speichert.

Ereignisse im Formularmodul. Ein Steuerelement löst seine Ereignisse im Modul des Formulars aus, auf dem es sitzt. Auf der Registerkarte Ereignis des Eigenschaftenblatts führt Access sie nicht auf; die Prozeduren legen Sie über die Designerseite Ereignisse oder die Listen des Codefensters an (Ereignisprozeduren für ein Steuerelement anlegen).

An die Daten gebunden wie ein Access-Steuerelement. Die Listen lesen eine RecordSource (Tabelle, Abfrage oder SQL-Anweisung) und schreiben Änderungen des Benutzers sofort zurück (AutoSave); für eine Struktur genügen RecordSource, KeyField, ParentField und TextField. Was die Datenherkunft zulassen muss, beschreibt Bearbeiten und Speichern: Voraussetzungen. In der Entwurfsansicht liest ein Steuerelement seine Datenquelle nur, wenn LivePreview auf True steht (Echte Daten in der Entwurfsansicht anzeigen).

Feste Fehlernummern. Die Steuerelemente lösen Fehler mit festen Nummern aus (Konstanten von WklErrorCode) und setzen Err.Source = "WklForms"; Texte, die Benutzer sehen, erscheinen in der Sprache der Komponenten (Fehler von WKL-Steuerelementen in VBA behandeln).

Sprache. Designer, Meldungen, Err.Description, Kontextmenüs und die Namen für Sprachausgaben sind Englisch, Deutsch, Slowenisch, Kroatisch oder Italienisch: in der Sprache des Anwendungsmodells, sonst der von Office, sonst der von Windows, sonst Englisch. Fehlernummern, Eigenschaftsnamen, gespeicherte Werte und IntelliSense sind in jeder Sprache gleich; Datums- und Zahlenformate folgen den Regionaleinstellungen von Windows (Sprache der Komponenten festlegen).

Farben. Jedes Steuerelement hat ein Farbschema (ColorScheme). Die Standardeinstellung Automatisch folgt zuerst dem hohen Kontrast von Windows, dann den Designfarben der Access-Datenbank (zum Beispiel „Riviera“) und verwendet sonst eine helle Palette; hell, dunkel und hoher Kontrast lassen sich auch fest einstellen. Die Steuerelemente folgen nicht dem Office-Design (Farbig, Dunkelgrau, Schwarz), das Office je Benutzerkonto speichert (Farben des Datenbankdesigns übernehmen).

Eine Typbibliothek, versioniert mit ihrer Schnittstelle. Eine Datenbank verweist auf die Typbibliothek WKL Forms Object Library und verwendet beim Öffnen die Version, die auf dem PC registriert ist; siehe Versionen.

• Freigegebenes Paket installieren
• Anwendung auf Release 2.0 umstellen
• Anwendung mit WKL-Steuerelementen auf Benutzer-PCs verteilen
• Anwendung für die Produktion ausliefern
• Was die Registrierung pro Benutzer schreibt
• Ablaufprotokoll der WKL-Steuerelemente für den Support aufzeichnen
• Lizenzierung

Jede Seite beschreibt das Symptom, die betroffenen Versionen, die Ursache und die Lösung.

• API-Referenz (Englisch) jeder Klasse und der Enumerationen: siehe die Spalte „Dokumentation“ unter Wichtige Funktionen; Auflistungen und ihre Elemente: WklColumns · WklColumn · WklBands · WklBand · WklFormatRules · WklFormatRule · WklLinkDifferences · WklLinkDifference
• Dateiformate: access-app.json · app-model.json · app-manifest.json · navpane.json

• CHANGELOG.md im Release-Paket – was jedes Release geändert hat
• Vorlage für den Anwendungsrahmen (im Paket unter templates\app-shell, beschrieben in der README dort) – der Rahmen einer Anwendung, gebaut vom Build-Werkzeug

Die Steuerelemente teilen sich eine Typbibliothek, WKL Forms Object Library, deren Version mit jeder Änderung der Schnittstelle steigt. Ein Release hat die Version x.y.z: x.y ist die Version der Typbibliothek, z zählt Korrekturen, die die Schnittstelle nicht ändern. Die Änderungen jedes Release stehen in der Datei CHANGELOG.md des Release-Pakets; das aktuelle Release ist 2.0.0.

Welche Version registriert ist. Je Bitversion ist immer nur eine Version registriert: Das Registrieren eines Releases entfernt für diesen Benutzer die Registrierung jeder anderen Version der Bibliothek, sodass eine Datenbank nie eine ältere Kopie aufgreift. So stellen Sie die Version fest:

• Im VBA-Editor zeigt Extras › Verweise für eine Datenbank, die die Steuerelemente verwendet, WKL Forms x.y Object Library an.

• In VBA:

  Dim r As Reference
  For Each r In References
      If r.Guid = "{A37D549E-FCD0-48EC-8B14-C7323B747E4F}" Then Debug.Print r.Major & "." & r.Minor, r.FullPath
  Next

• Die Komponenten nennen ihr Release selbst: WklApplication.Version gibt es zurück (1.55.0), WklApplication.Build das Release, ein Pluszeichen und die vollständige Commit-ID der Quellen (1.55.0+ce4b826c...). Nennen Sie Build in jedem Fehlerbericht.
• In den Dateieigenschaften (Registerkarte Details) zeigt Wkl.Forms.ObjectLibrary.dll das Release als Datei- und Produktversion, Wkl.Forms.ObjectLibrary.Managed.dll das Release mit der Commit-ID als Produktversion. Ein Build aus Quellen, die nicht committet wurden, trägt keine Kennzeichnung; ein Release-Paket wird immer aus dem Commit gebaut, den sein Tag nennt.

Kompatibilitätszusage. Einmal veröffentlicht, ändern sich Member mit ihren DISPIDs und Klassen mit ihren GUIDs nie mehr und werden nie entfernt; neue Releases fügen nur hinzu, und jede Ergänzung erhöht die Version der Typbibliothek. Formulare speichern die Einstellungen ihrer WKL-Steuerelemente im Formular (OleData), und ein neueres Release liest die Einstellungen, die ein älteres gespeichert hat; Einstellungen, die ein neueres Release hinzufügt, erhalten in Formularen aus einem älteren Release ihren Standardwert. Ein Korrektur-Release (z) ändert keinen Member.

Eine Datenbank mit einem Verweis auf eine ältere Version arbeitet mit einer neueren Registrierung derselben Hauptversion weiter: Access löst den Verweis beim Öffnen der Datenbank auf die registrierte Bibliothek auf. Mit Release 2.0 beginnt eine neue Hauptversion mit dem Bibliotheksnamen WklForms; eine gegen 1.x gebaute Datenbank wird einmal umgestellt (Anwendung auf Release 2.0 umstellen). Kompilieren Sie sie erneut (Debuggen › Kompilieren) und erstellen Sie eine neue ACCDE, bevor sie Member des neueren Releases verwendet. Umgekehrt funktioniert es nicht: Eine Datenbank, die gegen ein neueres Release gebaut wurde, läuft nicht mit einer älteren Registrierung – der Verweis ist unterbrochen (NICHT VORHANDEN), und Access meldet Fehler 459 oder dass die Objektbibliothek nicht registriert ist. Installieren Sie zuerst die Komponenten, dann die Datenbank (Anwendung mit WKL-Steuerelementen auf Benutzer-PCs verteilen). Bei UserForms in Excel und Word ist es anders: Office behält ab der ersten Verwendung eine Kopie der Bibliothek je Version; deshalb erhöht jede Änderung der Schnittstelle die Version.

Hauptversion 2.0. Zugesichert ist die Auflösung eines Verweises auf eine neuere Registrierung nur innerhalb seiner Hauptversion. Access bindet den Verweis einer Datenbank für 1.x über dieselbe Bibliotheks-ID zwar auch an Release 2.0, die ProgIDs WklComponents.* sind dann aber nicht mehr registriert. Release 2.0 hat den Namen der Bibliothek von WklComponents in WklForms geändert, die ProgIDs von WklComponents.* in WklForms.* und das Startmodul in Wkl.Forms.ObjectLibrary.dll. Member, DISPIDs und GUIDs sind dieselben wie in 1.68, Formulare behalten ihre Steuerelemente. Eine Anwendung für 1.x stellen Sie einmal um (Anwendung auf Release 2.0 umstellen).

Unterstützung je Steuerelement, jeweils in Microsoft 365 Access:

„Grundlegende Nutzung“ in UserForms von Excel und Word bedeutet: Das Steuerelement lässt sich auf einer UserForm einfügen, an seine Daten binden, aus VBA verwenden und mit der UserForm speichern; jede weitere Nutzung auf UserForms wird nicht unterstützt.

WklTreeView, WklTreeList, WklGantt und WklGrid schreiben eine Änderung des Benutzers – ein Umbenennen, ein Verschieben, eine Zelle, ein Häkchen, einen neuen, kopierten oder gelöschten Datensatz – sofort in die RecordSource (AutoSave = True, Standardwert). Ob das gelingt, hängt von der Datenherkunft ab.

• Die Datenherkunft muss in Access aktualisierbar sein – prüfen Sie, ob Sie in ihrem Datenblatt einen Wert ändern können. Eine Tabelle, eine Auswahlabfrage auf eine Tabelle und SQL-Text als RecordSource speichern; eine UNION-Abfrage, eine Abfrage mit GROUP BY, eine Pass-Through-Abfrage und eine verknüpfte ODBC-Tabelle ohne eindeutigen Index lehnen mit dem Fehler wkeSourceError (&H80040302) ab: „Die Änderung (Umbenennen) am Knoten 2 konnte nicht in “qUnion” gespeichert werden: Aktualisieren nicht möglich; Datenbank oder Objekt ist schreibgeschützt.“ Nichts wird gespeichert, und der Knoten behält seinen Text aus der Herkunft.
• Felder, die die Herkunft nicht schreiben kann, öffnen keinen Editor (WklGrid, WklTreeList, WklGantt, WklPropertyGrid): Mit AutoSave = True fragt die Liste die Herkunft einmal ab – Updatable und DataUpdatable von DAO, AutoWert-Felder und bei einer verknüpften ODBC-Tabelle den Treiber (IDENTITY-, berechnete und rowversion-Spalten). Solche Zellen verhalten sich wie ReadOnly. Mit AutoSave = False wird nichts abgeschaltet, weil die Anwendung die Änderung selbst schreibt. Hinzufügen, Löschen, Umbenennen in WklTreeView und Ziehen bleiben eingeschaltet: Die Ablehnung zeigt sich erst beim Speichern der Änderung. Bei einer Änderung des Benutzers wird die Transaktion zurückgesetzt, die Struktur neu geladen, DataError tritt mit dem obigen Text ein, und es folgt ein Meldungsfenster, sofern DataError den Parameter Response nicht auf acDataErrContinue (0) setzt. Für eine Herkunft, die sich nicht aktualisieren lässt, schalten Sie das Bearbeiten ab: AllowEditing = False (LabelEdit = False in WklTreeView), AllowAdditions = False, AllowDeletions = False und kein Drag & Drop.
• KeyField muss genau einen Datensatz kennzeichnen. Der Datensatz wird über seinen Schlüssel gefunden: bei einer Tabelle oder Abfrage per SQL (SELECT * FROM [source] WHERE [key] = …), bei SQL-Text mit FindFirst im Dynaset. Ein Schlüssel, der doppelt vorkommt, lehnt das Schreiben mit wkeDuplicateKey (&H80040303) ab: „Der Schlüssel 2 kommt in der Datenherkunft mehrfach vor. KeyField muss jeden Datensatz eindeutig kennzeichnen.“ Nichts wird gespeichert. Ein zusammengesetzter Schlüssel lautet KeyField = "OrderID;LineNo"; seine Felder gehen mit AND in dieselbe Bedingung ein.
• Verknüpfte ODBC-Tabellen (SQL Server, Wkl OData) brauchen in Access einen eindeutigen Index, den Access beim Verknüpfen aus dem Primärschlüssel übernimmt. Eine verknüpfte SQL-Server-Tabelle mit Primärschlüssel speichert; dieselbe Tabelle ganz ohne Index ist schreibgeschützt und lehnt wie oben ab. Das Steuerelement öffnet sein Dynaset mit dbSeeChanges, das SQL-Server-Tabellen mit einer IDENTITY-Spalte verlangen. Über den Wkl-OData-Treiber braucht eine Tabelle zum Schreiben außerdem eine Zeilenversion, unabhängig vom Typ ihres Schlüssels. Ohne sie sucht Access den Datensatz, indem es jeden alten Wert vergleicht (UPDATE … WHERE Id = ? AND Name = ?). Der Dienst bietet diesen Vergleich für eine Tabelle mit Schlüssel nicht an, und der Treiber lässt ihn auch nicht weg. Das Schreiben wird mit wkeSourceError abgelehnt: „[Wkl][OData]Die Bedingung auf 'Name' laesst sich nicht uebersetzen; … ein Vergleich mit dem alten Wert wird von diesem Dienst nicht angeboten.“ Zur Abhilfe fügen Sie der Tabelle entweder eine rowversion-Spalte hinzu oder schalten den Zeilenstempel des Dienstes für die Tabelle ein (siehe die Dokumentation des Dienstes). Verknüpfen Sie die Tabelle danach neu.
• Eine Transaktion, ein Ort. Jeder Schreibvorgang einer Benutzeraktion läuft in einer Transaktion des Standard-Arbeitsbereichs von DAO, auch der Zelleneditor von WklTreeList (BeforeUpdate mit Action = wuaCellValue). Cancel in BeforeUpdate oder eine Ablehnung durch Access setzt die ganze Aktion zurück und lädt die Struktur neu. Schreibvorgänge, die Ihr eigener Code in BeforeUpdate über CurrentDb ausführt, gehören zum selben Arbeitsbereich und werden mit zurückgesetzt. Cancel in ValidateCell greift vor jedem Schreibvorgang: Der Editor schließt, und die Zelle behält ihren alten Wert.
• Eine Datenherkunft für alle Knoten. Eine Struktur, deren Knotenarten über eine UNION-Abfrage aus mehreren Tabellen stammen, kann nicht direkt schreiben; es gibt keine Zuordnung von Knotenart zu Tabelle. Bearbeiten Sie eine solche Struktur stattdessen über Formulare: EditForms öffnet für den ausgewählten Knoten das Access-Formular seiner Art (sourceKeys nennt den Schlüssel des Datensatzes dahinter, deleteFrom die Tabelle, aus der gelöscht wird; siehe Datensätze in einem Access-Formular bearbeiten). Oder setzen Sie AutoSave = False und speichern die Änderung selbst: Die Struktur ändert dann nur ihre Anzeige, löst kein BeforeUpdate aus, und Ihre Behandlung von ValidateCell, AfterLabelEdit, NodeDrop oder BeforeDelete schreibt den Datensatz über seinen Schlüssel; setzen Sie dort Cancel, wenn Ihr Schreibvorgang fehlschlägt.

Vertrauen. Die Steuerelemente registrieren sich als sicher für Skripterstellung und Initialisierung, obwohl Member Dateien schreiben (SaveToFile, Export…, SaveImage), Dateien öffnen (AutoStart) und Dateien lesen, die in gespeicherten Eigenschaften genannt sind (WklImage, auch von einer Netzwerkfreigabe). Verwenden Sie sie nur in Datenbanken aus vertrauenswürdigen Speicherorten.

Wo ein Steuerelement auf einem Formular stehen kann (die Seite jeder Komponente beschreibt ihren eigenen Ausweg):

• Berichte: In einem Bericht zeigen die Listen (WklTreeView, WklTreeList, WklGantt, WklGrid, WklPropertyGrid) einen Hinweis statt der Daten; WklBarcode und WklImage sind für Berichte gemacht (ein gebundenes Steuerelement zeichnet den Wert jedes Datensatzes in Seitenansicht und PDF); die übrigen Steuerelemente werden in Berichten nicht unterstützt. Hierarchische Berichte entstehen mit Gruppierungsebenen und Unterberichten; die Ansicht einer Liste wird über ihren Export weitergegeben.
• Unterstützt: Access in 32 und 64 Bit. Die VBA-Module, die die Komponenten schreiben (basWklRibbon, das Modul des Build-Werkzeugs, das Add-In), deklarieren keine API-Funktionen; es gibt also kein PtrSafe anzupassen.
• Einstellungen für hohe DPI werden nicht unterstützt.
• Drag & Drop funktioniert nur innerhalb desselben Steuerelements: Knoten von WklTreeView, WklTreeList und WklGantt werden innerhalb ihrer eigenen Struktur verschoben oder kopiert; Zeilen von WklGrid lassen sich nicht ziehen (es nimmt nur Dateien aus dem Datei-Explorer an). Datensätze von einem Steuerelement auf ein anderes zu ziehen – zum Beispiel viele ausgewählte Personen auf eine Regel in einer zweiten Liste – ist nicht möglich. Stattdessen: Lassen Sie den Benutzer mit MultiSelect auswählen, lesen Sie SelectedKeys und führen Sie die Zuordnung über einen Befehl aus (eine Schaltfläche WklButton, einen Befehl des Kontextmenüs oder RowCommand); den Schlüssel des Ziels nehmen Sie aus SelectedKey des anderen Steuerelements. Beim Kopieren von Knoten werden Anlage- und mehrwertige Felder nicht mitkopiert.
• AutoSave schreibt nur in eine RecordSource, die Access aktualisieren kann, mit einem KeyField, das genau einen Datensatz kennzeichnet; eine UNION-, GROUP BY- oder Pass-Through-Abfrage und eine verknüpfte Tabelle ohne eindeutigen Index lehnen beim Speichern der Änderung ab, nicht vorher. Es gibt keine Zuordnung von Knotenart zu Tabelle. Eine Struktur, die aus einem Recordset oder einer Datei geladen wurde, hat keine Herkunft, in die sie zurückschreiben könnte. Siehe Bearbeiten und Speichern: Voraussetzungen.
• Der Filter eines gebundenen Steuerelements ist eine WHERE-Bedingung der Datenquelle und fragt sie jedes Mal ab; bei einer Pass-Through-Abfrage läuft die ganze Abfrage auf dem Server.
• Access führt das Fenster eines ActiveX-Steuerelements in UI Automation nicht als untergeordnetes Element seines Formulars. Sprachausgaben erreichen das Raster über den Fokus; eine Suche im Elementbaum von Access findet es nicht.
• NodeFormat und CellFormat werden nur mit FormatEvents = True ausgelöst. Jeder Ereignisaufruf in Access dauert einige Millisekunden, und die summieren sich bei jedem Neuzeichnen über alle sichtbaren Knoten oder Zellen.
• Export: XLSX, XML und JSON; WklGantt schreibt außerdem Bilder, PDF und Microsoft-Project-XML. Andere Formate (XLS, CSV …) gehören nicht zu den Steuerelementen: Öffnen Sie die XLSX-Datei in Excel und speichern Sie sie im benötigten Format, von Hand oder mit wenigen Zeilen VBA. Der Excel-Export in der angezeigten Form lässt Datenbalken und Symbolsätze aus, bei WklGantt außerdem Abhängigkeitspfeile, Basispläne und Stichtage (es gibt keine Zellenform dafür).
• WklGantt: Text im PDF ist Teil des Bildes und lässt sich nicht durchsuchen. Microsoft-Project-XML folgt dem Schema von Project 2007: Manuelle Planung, die Lücken unterbrochener Vorgänge und das Aussehen des Diagramms werden nicht ausgetauscht. Die Project-Dateien folgen dem von Microsoft veröffentlichten Schema und der Form von Project-2010-Dateien; das Öffnen in Microsoft Project selbst wird nicht unterstützt.

Die Steuerelemente und Objekte enthalten keine Lizenzprüfung: keinen Lizenzschlüssel, keine Prüfung in der Entwurfsansicht und keine zur Laufzeit, auch nicht in der Access Runtime oder auf UserForms in Excel und Word. Eine Datenbank, die sie verwendet, läuft auf jedem PC, auf dem das Release installiert und registriert ist (Anwendung mit WKL-Steuerelementen auf Benutzer-PCs verteilen). Es gelten die Nutzungsbedingungen Ihres Vertrags mit dem Lieferanten.