432 views
in Embedded Wizard Studio by
Dear Sir,

Can you tell me how to use macro to change the directory of the unit while the path of project and the path of the software is different.

tks

1 Answer

0 votes
by

It is not possible to use a Chora macro for the Directory attribute of a unit. Changing the location of a unit would require this unit to be reload into the current project data-base.

May be you are confused by the $Mosaic20 entry. Here the $ sign doesn't start a macro name. It represents the root directory of your Embedded Wizard installation. The string $Mosaic20 means thus, that the unit is taken (or stored) in the folder Mosaic20 relative to folder where you have installed the Embedded Wizard. Usually you will never need to use this special $ notation for the Directory attribute. It is necessary only to find and access units belonging to the component frameworks delivered with Embedded Wizard.

Nevertheless, you can store the project and unit files in separately in different locations. Per default new units are stored in the same folder where the project file exists (the attribute Directory is '.\'). You can change the attribute and e.g. store a unit in a sub-directory relative to the project directory '.\SomeFolder', or '..\..\..\AnotherFolder'. By using the fullpath notation you can specify any location within your file system: 'E:\SomeProjectFolder\SomeUnitFolder':

by
Thank you for the answer.
But, we want to use $ to locate one unit with different .ewu files, and than we can use one project to implement different style with the same unit name. So, we want to use the profile to define macro to locate the .ewu file. How can I do this?
by
When using a single project file, such application case is not possible. Let me explain the background of the technology.

Embedded Wizard works internally with a data-base. When you open the project, the content of all associated units is loaded into the data-base. From this moment, all subsequent operations in Embedded Wizard take place on this data-base only.

While you are working with Embedded Wizard, the data-base is permanently evaluated. So all the contents shown in  Composer, Inspector, etc. are taken from the data-base. This approach is essential especially in context of the object-oriented characteristic of Embedded Wizard.

The data-base provides thus an overview about the dependencies between project members, their inheritance, and much more. Every time you change something in your project, the data-base is updated and the Composer, Inspector and other editor windows are notified to refresh themselves.

The unit files play a role again when you save the project only. Then the current content of the data-base is stored back in the unit files. This is an essential difference to other development tools, where the user edits permanently the code directly within the files.

Anyway if it is essential for your project to select a unit file depending on the configuration, I would suggest following simple workaround. Create several copies of your project file (of the *.ewp file) - one for each configuration. Thereupon in all project files you can share the same units except the few which are configuration specific. Here you can modify every project to use a different version of such special units.

You will, however, need to switch between the projects. Of course you can start multiple instances of Embedded Wizard and so work on all projects simultaneously - every project in a separate Embedded Wizard window.

The above solution addresses directly your particular question of using several versions of a unit within a single project. I suppose, your intention is to switch the GUI look/feel depending on the currently selected profile. You want several homonymous units to implement different variants of GUI. Is it correct?

Well, in such case Embedded Wizard provides a technique to allow you to have resources, constants and even classes in several variants and to switch between these variants. You can determine the desired variant statically at the code generation time depending e.g. on the currently selected profile or you can switch them dynamically at the runtime. The concept of variants is based on the object-oriented paradigm of inheritance. The variants are simply derived from their original member (e.g. from a class).

Let's assume, you want to implement a menu component for two different screen resolutions. In such case you could develop first the component for the first resolution. Then you derive from this component a variant. This variant can be edit in the same manner as you do with the original component. You could re-arrange the views within the variant and change their attributes so they appear correctly for the second resolution. Even you can override the inherited methods, so the variant would behave differently.

To determine whether a variant is used or not is controlled by its attribute VariantCond. Here you can determine e.g. that the variant is used for the Profile XYZ. When you generate the code for XYZ, the variant is taken in account. When you generate the code for any other profile, the original menu implementation is used. The selection occurs thus automatically.

More about variants can be found in 'Chora User Manual' and in 'EmWi Tutorial - Mosaic 2.0'.

Does it help you further?
by
Thanks a million

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...