FAQ – Häufig gestellte Fragen

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).

Der IDM arbeitet intern mit Instanzen von Objekten. Für das Lesen und Schreiben einer Dialogdatei wird der Objektbaum inklusive des Regelcodes zur besseren Lesbarkeit formatiert gespeichert und beim Laden die Objektstruktur wieder aufgebaut. Dabei verwendet der IDM die eingestellten Einrückungen.

Kommentare bleiben im Quellcode des Dialogs erhalten, wenn sie mit doppelten Ausrufezeichen markiert werden:

!! In Liste wird etwas selektiert, darum werden die
!! Pushbuttons Löschen und Informationen freigeschaltet

Bei benutzerdefinierten Attributen lassen sich Kommentare übrigens dirket bei der Definition erstellen.

Im grafischen IDM-Editor stellt man im entsprechenden Textfeld das „@“ voran und gibt dann den Namen der Textressource an.
Wenn Sie den Dialog direkt in einem Texteditor bearbeiten, geben Sie nur den Namen der Textressource an.

Zu diesem Zweck gibt es die eingebaute Funktion setinherit().

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.

Nein, das ist nicht möglich.

Nein, und das mit gutem Grund. Änderungen an dem Objekt könnten unerwünschte Auswirkungen in dem Modul und andere Dialoge, die das Modul verwenden, haben.

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) werden nur als Zeichenkette angelegt.
Text-Objekte können mit mehrsprachigen Varianten versorgt werden und verbrauchen trotz mehrfacher Nutzung nur einmal Speicher.
Strings benötigen keine ID, können aber keine Varianten haben und verbrauchen je String Speicher.

Ab Version A.06.01.a werden Strings, die mehrfach vorkommen, intern gespeichert, um Speicher zu sparen.

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).

Hinweis:
.content[] wird von Modellen oder Defaults nicht geerbt!

Ü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.

aber:
Die Länge und Cursorpositionen sind begrenzt auf 2 GB

Theoretisch können in einem Poptext bis zu 65.000 Einträge gespeichert werden.

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.

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.
Bei benutzerdefinierte Methoden ist das nicht möglich.

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

Nicht jedes Attribut kann ein changed-Ereignis auslösen.

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

Im Prinzip gibt es zwei Event Queues.

Queue 0: Regelverarbeitung
Queue 1: changed-Ereignisse und externe Ereignisse

Die Meldung deutet darauf hin, dass die Regelverarbeitung zu lange dauert. In diesem Fall sollte man die Regelverarbeitung anders lösen.

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.

Außerdem können Sie eine Liste, die alle erforderlichen Werte enthält, als Parameter übergeben.

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.

In der Portierungslizenz sind die Entwicklungsbibliotheken nicht enthalten, aber sie enthält alles, was für den Bau der Anwendung  ist es möglich, die Anwendung zu bauen.

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

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.

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

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

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.

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.

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 Bearbeitungsnummer mit.

Per E-Mail (idm-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.

Die größte Herausforderung bei der Fehleranalyse ist es oft, den Fehler lokalisieren. Dazu bietet der IDM verschiedene Möglichkeiten:

Lässt sich ein Fehler reproduzieren, ist es hilfreich, ein Tracefile generieren (idealerweise vollständig). Damit lässt sich die Fehlerursache meist gut lokalisieren.

• Sollte das Problem/der Absturz in Ihrer eigenen Anwendung auftreten, sollten Sie Debugger und andere Komponenten zu Rate ziehen.
• Zusätzlich zum Tracefile stellen wir ggf. für die IDM-Diagnose Dumpstate und Debugger zur Verfügung.

Haben Sie keine Lösung für Ihr Problem gefunden, wenden Sie sich an unseren Support.

• Den Fehler kategorisieren (Absturzart/Ort, IDM/eigene Anwendung/Umgebung, …).
• Stellen Sie uns ein Tracefile zur Verfügung
• Hilfreich ist auch ein kleiner Beispieldialog, mit dem sich das Problem reproduzieren lässt.

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

• Über die Umgebungsvariable IDM_TRACEFILE 
• Über den Parameter -IDMtracefile <Dateiname.trc> 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.