FAQ - Frequently Asked Questions

The display of umlauts is controlled by a number of components:

Which font is used (does it have the required umlauts?); which locale and code page is set for the application and which for the display; does the toolkit support these umlauts? etc.
As I said, there are a lot of screws that can be turned and that may be incorrectly adjusted.
The IDM itself uses UTF-8 and therefore supports Unicode.

With the attribute .language at the setup-Object after the DM_Initialize.
It is best to do this before the objects become visible and already have text (before DM_StartDialog).

The IDM works internally with object instances. When reading and writing a dialog file, the object tree, including the rule code, is saved formatted for better readability. The object structure is rebuilt upon loading. Therefore the IDM uses the configured indentations.

Texts that are to be displayed in multiple languages ​​can be defined as text resources.

e.g.

text TxCancel "Cancel" { 2: "Abbrechen"; }
text TxMiQuit "&Quit" { 2: "&Beenden"; }

But it's not just text that can be defined with (language) variants. This mechanism is also a good choice for images, input and output formats, colors, and fonts.

Comments are preserved in the dialog source code if they are marked with double exclamation marks:

!! Something is selected in the list, so the
!! pushbuttons delete and information are enabled

For user-defined attributes, comments can be created directly during definition.

In the graphical IDM Editor, you place the “@” in front of the corresponding text field and then enter the name of the text resource.
If you edit the dialog directly in a text editor, only specify the name of the text resource.

For this purpose you can use is the built-in function setinherit()

Since the order of inherited children cannot be changed, it is helpful to create a maximum number of menu items in the model. Unneeded menu items can then be hidden. This way, you can always define existing menus in advance.

No, that is not possible.

No, and for good reason. Changes to the object could have undesirable effects in the module and other dialogs that use the module.

Approximately 4,000 modules/dialogs are possible per application.

Texts in the .text and .title attributes are created as objects by the IDM and are given an internal ID.
Strings (e.g. in the attribute .content) are only created as a character string.
Text objects can be provided with multilingual variants and, despite multiple uses, only consume memory once.
Strings do not require an ID, but cannot have variants and consume memory per string.

Starting with version A.06.01.a, strings that occur multiple times are stored internally to save memory.

The IDM must search the entire application for references to this object and resolve them. This process can take a very long time, depending on the application.

The content of a table field is determined by the dynamic attribute .content . The values ​​of this attribute are written into the code when writing binary data. If variable values ​​are to be displayed, this could be done, for example, via the :init() method on the table field.

On the one hand, to make it clear that there are strings that support multilingualism and use IDs as objects (.text, .title). On the other hand, to clarify that strings have a rather dynamic background (.content).

Notice:
.content[] is not inherited by models or defaults!

Using the Tab key.

The number of objects per dialog/module/child objects is approximately 65,000.

The IDM doesn't specify string length. If there are limitations, it's usually due to the toolkit.

but:
The length and cursor positions are limited to 2 GB

Theoretically, up to 65,000 items can be stored in a poptext.

Since poptext stores the content as a text object, this depends on how many object IDs are still available. Sometimes the toolkit limits the number.

These objects can each consist of 65,000 rows. The tablefield also consists of 65,000 columns.
However, limitations could arise beforehand due to the toolkit, which uses the required memory for fonts or images used on the objects (e.g. treeview).

Font sizes and image dimensions influence the number of possible nodes.

Motif:
only about 1000-2000 nodes are possible here.

No, event rules are called by the IDM when the event is triggered.
However, you can define your own events and trigger them with sendevent() or work with self-defined methods.

User-defined attributes are completely dynamic. They can be created, modified, and deleted at runtime.
This is not possible with user-defined methods.

":=" triggers a changedEvent, "::=" doesn't.

Not every attribute can trigger a changedEvent

These queues store events that occur in an application. They are processed according to the FIFO (first in, first out) pattern.

In principle there are two event queues.

Queue 0: Rule processing
Queue 1: changedevents and external events

This message indicates that rule processing is taking too long. In this case, you should resolve the rule processing differently.

The maximum recursion depth is approximately 1,000.

If this limit is exceeded, the following information is displayed: ***ERROR IN EVAL: too many levels of rule recursion (1000)

Attributes can be stored in variables/attributes of the data type "Attribute". Access is possible via the built-in functions getvalue() and setvalue() .

If you want to store rules or functions in variables and attributes, you must note that these are of the data type “object” in the rule language.
Methods are of the data type "method." Rules and functions can then be called directly via the variable name or attribute.
Methods can be accessed via the built-in method :call() indirectly.

A certain degree of variability is achieved through so-called "records" as parameters, which have different attributes and can also be dynamically created, assigned, and read. We would also like to point out the possibility of optional parameters here.

You can also pass a list containing all required values ​​as a parameter.

The size limit for rules and methods is 64kB. If this limit is exceeded, the dialog will not start and the trace file will output the following information:

[F: rule exceeds internal size - ]

Therefore, it may be necessary to split rules or methods.

Basically, even allocated memory must be released again.

First the system's "includes" should be specified, then those of the IDM.

If a suitable IDM version is available for the target platform, we recommend using that version. If no suitable version is available, please contact our support team.

Yes, it also requires a developer version.

The porting license does not include the development libraries, but it does include everything needed to build the application.

A developer license also includes the graphical IDM editor, the debugger and the profiler.

You can log in to our FTP server (ftp.isa-tools.de). You will receive the login information from our support team.

After registering on our website, versions can be downloaded from the Download area.

The Qt window system is supported starting with IDM version A.06.01.a.

This error message occurs if the IDM was not installed correctly or without the documentation.

When Windows is shut down, the windows receive the closeEvent, that you can react to.

Another possibility is to catch window system messages (WM_QUERYENDSESSION/WM_ENDSESSION) via a DM_InputHandler and then perform the desired actions.

Monday to Friday, 9am to 4pm.

A precise problem description (what, when, how, where). Include: IDM version, platform/toolkit, window manager, and environment components.

Sample code to reproduce the error. A trace file of the process. Screenshots and videos demonstrating the error.

If a bug you reported has been fixed or a request has been implemented, you will automatically receive a new version or a notification that it is ready for download.

If you have any questions about specific errors or requests for enhancements, please let us know the corresponding processing number.

By email (idm-support@isa.de) and in urgent cases via the hotline (+49 711 22769-24).

The Documentation (DE/EN) is linked in the menu item of the same name in the Support section on our website.

The biggest challenge in error analysis is often locating the error. The IDM offers several options for this:

If an error can be reproduced, it is helpful to generate a trace file (ideally a complete one). This usually makes it easier to pinpoint the cause of the error.

• If the problem/crash occurs in your own application, you should consult debuggers and other components.
• In addition to the trace file, we may provide dumpstate and debugger for IDM diagnostics.

If you have not found a solution to your problem, please contact our support.

• Categorize the error (crash type/location, IDM/own application/environment, …).
• Send us a trace file
• A small example dialog that can be used to reproduce the problem is also helpful.

A trace file logs the application's execution. It can be created in the following ways:

• About the environment variable IDM_TRACEFILE 
• About the parameter -IDMtracefile <Dateiname.trc> when starting the application

The start parameter overrides the environment variable.
The trace file can be configured in various ways (see the documentation chapter Start Options). Please note that a truncated trace file may not contain all the necessary information.

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