MUI entries can have the same ID pointed by TextID member of MUI_ENTRY structure. For this matter, altering a certain entry such as deleting a portion of text with MUIClearStyledText() only removes that portion of text when the given ID argument and the retrieved ID match.
However, MUIClearStyledText() only removes the first instance of text in the console leaving other entries with the same ID as is. Therefore we must ensure that we also iterate over other entries with the same ID as well. Besides the aforementioned function, do the same with MUIClearText(), MUISetText() and MUISetStyledText() too.
CORE-12683
Supersedes PR #612.
* [USETUP] Implement the internal MUI routines for text manipulation based on its ID and implement text resource based IDs
USETUP (the 1st stage text mode setup module) bases upon MUI (Multilingual User Interface) sub-component of USETUP which is responsible for the ability into translating the MUI pages (each page having corresponding properties like X, Y coordinates, text flags and text string buffer) in various languages.
The only problem, as of now, is that whenever you want to modify a certain property of a page, such as removing a text from the said page in the screen, you've got to rely on using CONSOLE_* specific functions and calling with hardcoded parameters, namely the coordinates.
This can become a problem as not every localized (translated) MUI page has the same properties for each language and this could lead to various issues. Therefore, assigning each entry with an ID you can remove a text by only giving its ID (and the entry page number) without having the need to specify the coordinates
as the internal MUI routine, MUIGetEntry(), automatically retrieves the entry with respective data fields.
The following commit implements:
- MUIGetEntry()
- MUIClearText()
- MUIClearStyledText()
- MUISetText()
- MUISetStyledText()
- Now the X and Y coordinate members of MUI_ENTRY are of SHORT integer type, for the sake of the general code as most of the coordination values, even the COORD structure itself, has the coordination points as SHORTs and not BYTEs.
The following MUI functions will be used to manipulate text based resources depending on their ID from the corresponding MUI entry.
* [USETUP] Make CONSOLE_ClearTextXY function public so that we can use across other files.
* [USETUP] Implement the IDs for each text MUI entry in locale files.
This mechanism follows the same principle of resource IDs in Win32 applications. Static text is merely a resource that doesn't get changed programmatically for whole of its lifetime whereas dynamic resources can change during the lifetime of the program depending on the algorithm (for example, hide that piece of text and set another one, etc.).
* [USETUP] Remove the "Press ENTER to continue" message prompt when the partition formatting begins.
[USETUP] Improve usage of ERROR_TXTSETUP_SECTION and ERROR_CABINET_SECTION error codes, correctly display associated error message, and remove a deprecated string.
[SETUPLIB] Copy the mui* files from usetup into the setuplib for later usage, and add mui.c to build.
svn path=/branches/setup_improvements/; revision=75711
[SETUPLIB][USETUP] Start massaging the MUI files and split up what concerns only the usetup "resources",
and what concerns general language parameters (in the setuplib).
It may be interesting to retrieve the language parameters
from INF file (e.g. intl.inf) (suggested by Giannis).
svn path=/branches/setup_improvements/; revision=75715
[SETUPLIB] Add the necessary headers to mui.c to be able to compile.
[USETUP] Comment out the languages that don't have any resources.
svn path=/branches/setup_improvements/; revision=75716
[SETUPLIB][USETUP] Adjust MUI and settings code.
- Re-enable settings code concerning language, keyboards & layout
in the setuplib, and remove the old code in usetup.
- Remove useless code in setuplib's mui.c.
- Rename usetup's MUI "LanguageList" into "ResourceList" so as to
avoid colliding with the "LanguageList" of setuplib.
- Add the magic CMakeLists line "add_definitions(${I18N_DEFS})" that
I forgot previously, that caused the "LanguageList" of setuplib to be empty!
The code compiles and works during my tests.
svn path=/branches/setup_improvements/; revision=75717
[SETUPLIB] Change some string pointer types & function prototypes so that the usetup-specific
"SelectedLanguageId" variable is not used in the library.
svn path=/branches/setup_improvements/; revision=75719
[SETUPLIB] Change some function prototypes so that the usetup-specific "SelectedLanguageId" variable is not used in the library.
Also, make AddEntriesFromInfSection(), DefaultProcessEntry() and the typedef PPROCESS_ENTRY_ROUTINE private again.
svn path=/branches/setup_improvements/; revision=75720
svn path=/branches/setup_improvements/; revision=75724
[USETUP] Code adaptations.
- Transform some do{}while() loops into while(){} ones, since the lists on which we work may only contain one single {NULL} element.
- Modify MUIGetOEMCodePage() call after r75719.
- Use PCWSTR where needed.
svn path=/branches/setup_improvements/; revision=75722
[USETUP] Adjust some MUI & settings calls, following the commits r75719, r75720 and r75721.
svn path=/branches/setup_improvements/; revision=75723
[INPUT.CPL] Adjust inclusion of "muifonts.h" (commit 3dbd44f) due to changes introduced in r75711 and r75715.
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
