Build 255 - RC

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Hello,

    The release candidate of the build 255 of the Unicode version is available.

    Please login to see this link.

    Note: you can also install this beta with the "Build 255 - RC" global patch available in the MMF2 Owners forum, it contains this update and doesn't prompt you for your serial number.

    Thanks for testing!

    Yves.


    Bug fixes in build 255 - RC

    - new Banned Extensions tab in the Preferences. Allows you to ignore some extensions when MMF2 starts. For example if you use both the normal and Unicode versions of MMF2, you can ignore crashing EDIF extensions only in the Unicode version. Also, when an extension crashes MMF at start, the new build automatically detects it when you restart it and the crashing extension is added to the Banned Extensions tab.
    - Unicode version : the Edit Box, List Box and Combo Box objects are now able to load UTF-8 text files that start with the UTF-8 mark.
    - Unicode version : display issues (and/or crash) in the Event editor when the Execute External Program action is displayed.


    Bug fixes in beta 3

    - Fix in the drag & drop object in scrolling application, in the PC and Java runtimes.


    Bug fixes in beta 2

    - PC runtime : applications that contain objects without Data/Runtime MFX file could crash when you ran them from MMF2.


    Bug fixes in beta 1

    - INI object : new UTF8 option in the properties. When this option is selected, strings are written in UTF8 format in the INI file. This option is selected by default in new objects only, in old applications you have to select it manually if you want to use it. When this option is not selected, the characters are written in the current Windows character set, causing issues for example if you write Greek, Japanese or Chinese characters on an English machine.
    - PC runtime : crash when you use several instances of the same global object and several of these instances have different alterable strings (this issue had been fixed previously, but not entirely).
    - Hmm... there are other fixes, but given the number of beta versions that were made for the exporters, I can't find which ones are in this version compared with the previous one... sorry...

    Thanks for update!
    However, the problem of the Ini with UTF-8 I've reported still not fixed.

    - The ini file doesn't load if including Japanese characters in file path.
    - The Editbox can't load the UTF-8 ini file because UTF-8 texts saved by Ini without UTF-8 mark.

    Quote from ASD

    - The Editbox can't load the UTF-8 ini file because UTF-8 texts saved by Ini without UTF-8 mark.

    ASD, ANSI and UTF-8 are very similar, but they aren't exactly the same. You cannot assume UTF-8 as ANSI is more common, so I'll recommend adding the encoding mark.

    Quote from Phi

    You can add the UTF-8 BOM mark by prepending 3 bytes with values 0xEF 0xBB 0xBF to the start of the file. In decimal terms, that's 3 bytes, 239 187 191. You can add it with the Binary object. Or a CT dude could add that functionality to an extension :)

    Darkwire Software Lead Programmer (C++ & C#)
    Please login to see this link. | Please login to see this link. | Please login to see this link. | Please login to see this link.

    Edited once, last by Phi (May 27, 2012 at 11:14 PM).

    Quote from ASD

    Thanks for update!
    However, the problem of the Ini with UTF-8 I've reported still not fixed.

    - The ini file doesn't load if including Japanese characters in file path.
    - The Editbox can't load the UTF-8 ini file because UTF-8 texts saved by Ini without UTF-8 mark.

    ASD, I don't know how to fix the problem with the Japanese characters in the filename of INI files with the UTF8 option.

    When the UTF8 option is OFF, I use the Unicode version of the Windows function to read INI files. The Unicode version supports Unicode filenames
    but it converts texts in INI files using the current character set of the system (as INI files contain MBCS text).

    When the UTF8 option is ON, I use the non-Unicode version of the INI API and I manually convert the text from UTF8 to Unicode.
    Problem, the non-Unicode version of the API doesn't support Unicode characters. I convert the filename to UTF8 too otherwise
    this will cause issues (for example if the filename contains Japanese characters and you run the application on an English machine that won't work).
    So the filename will be in UTF8 format too. Better use simple ANSI characters for the filename when you use the UTF8 option.

    About the second problem, this is normal. The Edit box object only loads UTF8 files that have the UTF8 mark at start. We would need to add a new "Load UTF-8" action to load INI files in UTF8 format because INI files are simple text file without byte order mark.

    Hmm,,, How I can detect the Japanese character from the path of the application?
    I would like to prevent execution of the application if it detect the Japanese characters in path of the application.
    Probably most Japanese users will put the application directory in the directory of used Japanese characters.

    EDIT: I can avoid to above problem by current directory command (.\directoryname)

    Other problem. The INI file with UTF-8 is cannot use the Japanese characters in group and item name?

    Edited 2 times, last by ASD (May 28, 2012 at 8:26 PM).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login