FAQ – Häufig gestellte Fragen

Im grafischen IDM-Editor stellt man im entsprechenden Textfeld das „@“ voran und gibt dann den Namen der Textressource an.
Im Texteditor gibt man nur den Namen der Textressource an.

Da die Reihenfolge bei geerbten Kindern nicht geändert werden kann, ist es hilfreich eine maximal benötigte Anzahl von Menüeinträgen im Modell anzulegen. Die nicht benötigten Menüeinträge können dann unsichtbar geschaltet werden. So kann man immer vorhandene Menüs schon vorab definieren.

Pro Anwendung sind ca. 4.000 Module/Dialoge möglich.

Texte in den Attributen .text und .title werden vom IDM als Objekte angelegt und bekommen eine interne ID.
Strings (z.B. im Attribut .content) wird nur als String angelegt.
Text-Objekte können mit mehrsprachigen Varianten versorgt werden und verbrauchen trotz mehrfacher Nutzung nur einmal Speicher.
Strings verbrauchen keine ID, können aber keine Varianten haben und verbrauchen je String Speicher.

Der IDM muss die gesamte Anwendung auf Referenzen zu diesem Objekt durchsuchen und auflösen. Dieser Vorgang kann, je nach Anwendung, sehr lange dauern.

Der Inhalt eines Tablefields wird über das eher dynamische Attribut .content angegeben. Die Werte dieses Attributs werden beim Binärschreiben fest in den Code geschrieben. Sollen variable Werte angezeigt werden, könnte das z.B. über die :init()-Methode am Tablefield gesteuert werden.

Einerseits um deutlich zu machen, dass es Zeichenketten gibt, die Mehrsprachigkeit unterstützen und als Objekte IDs verwenden (.text, .title). Andererseits um zu verdeutlichen, dass Zeichenketten einen eher dynamischen Hintergrund haben (.content).

Über die Tab-Taste.

Die Anzahl der Objekte pro Dialog/Modul/Kindobjekte liegt bei ca. 65.000.

Der IDM macht keine Vorgaben zur Stringlänge. Falls es Begrenzungen gibt, liegt es meistens am Toolkit.

Da der Poptext den Inhalt als Textobjekt speichert, hängt es davon ab, wie viele Objekt-IDs noch zur Verfügung stehen. Manchmal beschränkt das Toolkit die Anzahl.

Diese Objekte können aus jeweils 65.000 Zeilen bestehen. Das Tablefield besteht zusätzlich aus 65.000 Spalten.
Einschränkungen könnten allerdings zuvor durch das Toolkit entstehen, das den benötigten Speicher für an den Objekten eingesetzten Schriftarten oder Bildern (z.B. Treeview) nutzt.

Nein, Ereignisregeln werden beim Auslösen des Ereignisses vom IDM aufgerufen.
Man kann allerdings eigene Ereignisse definieren und über sendevent() auslösen oder aber mit selbst definierten Methoden arbeiten.

Benutzerdefinierte Attribute sind vollständig dynamisch. Sie können zur Laufzeit erzeugt, verändert und gelöscht werden.
Benutzerdefinierte Methoden sind nicht dazu geeignet.

“:=” löst ein Ereignis aus, “::=” nicht.

Diese “Queues” speichern Ereignisse, die bei einer Anwendung anfallen. Sie werden nach dem FIFO-Schema (first in-first out) abgearbeitet.

Die maximale Rekursionstiefe beträgt ca. 1.000.

Wenn diese Grenze überschritten wird, wird folgende Information ausgegeben: ***ERROR IN EVAL: too many levels of rule recursion (1000)

Attribute kann man in Variablen/Attributen vom Datentyp “Attribute” speichern. Der Zugriff kann über die eingebauten Funktionen getvalue() und setvalue() erfolgen.

Möchte man Regeln oder Funktionen in Variablen und Attributen speichern, muss man beachten, dass diese in der Regelsprache vom Datentyp “object” sind.
Methoden sind vom Datentyp “method”. Regeln und Funktionen können dann unmittelbar über den Variablennamen bzw. das Attribut aufgerufen werden.
Methoden können über die eingebaute Methode :call() indirekt aufgerufen werden.

Eine gewisse Variabilität erreicht man durch sog. “records” als Parameter, die unterschiedliche Attribute haben und auch dynamisch erzeugt, belegt und ausgelesen werden können. Auch auf die Möglichkeit von optionalen Parametern möchten wir hier hinweisen.

Die Größenbegrenzung für Regeln und Methoden liegt bei 64kByte. Wird die Begrenzung überschritten, startet der Dialog nicht und das Tracefile gibt folgende Information aus:
[F: rule exceeds internal size – ]
Deshalb kann es unter Umständen notwendig sein, Regeln oder Methoden aufzuteilen.

Grundsätzlich gilt, selbst allokierter Speicher muss auch wieder freigegeben werden.

Erst sollten die “includes” des Systems, dann die des IDM angegeben werden.

Falls es für die Zielplattform eine passende IDM-Version gibt, empfehlen wir den Einsatz dieser Version. Sollte keine entsprechende Version verfügbar sein, setzen Sie sich bitte mit unserem Support in Verbindung.

Ja, er benötigt ebenfalls eine Entwicklerversion.

Eine Entwicklerlizenz beinhaltet zusätzlich den grafischen IDM-Editor, den Debugger sowie den Profiler.

Wenn ein von Ihnen gemeldeter Fehler behoben oder ein Wunsch implementiert wurde, erhalten Sie automatisch eine neue Version oder den Hinweis, dass diese zum Herunterladen bereit steht.

Bei Nachfragen zu einzelnen Fehlern und Erweiterungswünschen, teilen Sie uns bitte die entsprechende 5-stellige Bearbeitungsnummer mit.

Sie können sich an unserem ftp-Server (ftp.isa-tools.de) anmelden. Die Anmeldeinformationen erhalten Sie von unserem Support.

Nach Registrierung auf unserer Website können Versionen im Bereich Download heruntergeladen werden.

Wird Windows heruntergefahren, erhalten die Fenster vom System das close-Event, auf das man reagieren kann.

Eine andere Möglichkeit ist, Fenstersystemmeldungen (WM_QUERYENDSESSION/WM_ENDSESSION) über einen DM_InputHandler abzufangen und dann die gewünschten Aktionen auszuführen.

Diese Fehlermeldung tritt auf, wenn der IDM nicht korrekt oder ohne die Dokumentation installiert wurde.

Das Fenstersystem Qt wird ab der Version IDM A.06.01.a unterstützt.

Von Montag bis Freitag, von 9 bis 16 Uhr.

Eine präzise Problembeschreibung (was, wann, wie, wo). Angaben: IDM-Version, Plattform/Toolkit, Window-Manager, Umgebungskomponenten.

Beispielcode um den Fehler zu reproduzieren. Ein Tracefile zum Vorgang. Screenshots und Videos auf denen der Fehler nachvollziehbar ist.

Per E-Mail (support@isa.de) und in dringenden Fällen über die Hotline (+49 711 22769-24).

Die Dokumentation (DE/EN) ist im gleichnamigen Menüpunkt im Bereich Support auf unserer Website verlinkt.

• Zunächst den Fehler lokalisieren.
• Ein Tracefile generieren (idealerweise vollständig).
• Den Fehler kategorisieren (Absturzart/Ort, IDM/eigene Anwendung/Umgebung, …).
• Zusätzlich zum Tracefile stellen wir ggf. für die IDM-Diagnose Dumpstate und Debugger zur Verfügung.
• Sollte das Problem/der Absturz in Ihrer eigenen Anwendung auftreten, sollten Sie Debugger und andere Komponenten zu Rate ziehen.
• Haben Sie keine Lösung für Ihr Problem gefunden, wenden Sie sich an unseren Support.

Ein Tracefile protokolliert den Ablauf der Anwendung. Es kann auf folgende Arten erstellt werden:

• Über die Umgebungsvariable IDM_TRACEFILE
• Über den Parameter –IDMtracefile beim Start der Anwendung

Der Startparameter überschreibt die Umgebungsvariable.
Das Tracefile kann auf verschiedene Weisen konfiguriert werden (s. in Dokumentation Kapitel Startoptionen). Bedenken Sie, dass ein gekürztes Tracefile eventuell nicht alle notwendigen Informationen enthält.

Über die Option –IDMtracetime (s. Dokumentation) oder den Profiler im Debugger können solche Stellen im Code ausfindig gemacht werden.

Die Darstellung von Umlauten wird von einer Reihe von Komponenten gesteuert:

Welcher Font wird genutzt (verfügt er über die erforderlichen Umlaute?); welches „locale“ und welche Codepage ist gesetzt für die Anwendung und welche für die Anzeige; unterstützt das Toolkit diese Umlaute? Usw.
Wie gesagt, das sind viele Schrauben, an denen man drehen kann und die evtl. falsch eingestellt sind.
Der IDM selber verwendet UTF-8, unterstützt somit Unicode.

Über das Attribut .language am setup-Objekt nach dem DM_Initialize.
Am besten, bevor die Objekte sichtbar werden und schon Texte haben (vor DM_StartDialog).