[SOLVED] U9.7 on W10 and new fonts freshly installed

Author: gianni.sandigliano@unifacesolutions.com (gianni)

Hi all, I know I am missing something here but after 4hours of free practice my brain is starting to overheat like Renault F1 engine 2014...rattle rattle... My goal is to use some barcode fonts freshly installed on Windows10 64bit from U9.7 32bit. After installing those fonts in Windows I've tried to use them from Word 2016 64bit => SUCCESS! On the same machine I've also U9.6.08 32bit already installed; I've defined some logical fonts into \Uniface\adm\usys.ini and used them from within IDF => SUCCESS! Then U9.7.01.G104: - added some logical fonts on file \Uniface\adm\usys.ini => NO success! - added same logical fonts on file \Common\adm\usys.ini => NO success! The IDF instance I am trying with is the default icon installed from standard Uniface installation process; I've just changed default dir names. After all my changes to INI files I countinue to see only logical fonts defined by Uniface at install time... - I've rebooted after installing them and rebooted again to avoid possible system issues => NO success! - I've tried to take out empty lines from .INI => NO success! - I've googled a lot... NO success! Any help is appreciated...thanks in advance! Gianni

5 Comments

  1. Hi Gianni, Just for pinpointing your problem: - Do you have Uniface 9.7 installed in the default C:\Program Files...? ->Then please try 'Run as administrator for your IDF.exe and/or uniface.exe  This has helped me in similar cases. Please also check this issue... Cheers, Arjen


    Author: Arjen van Vliet (arjen.van.vliet@uniface.com)
  2. Thanks Arjen! "Run As Administrator" did the trick... I do not understand why administrative privileges are involved considering how fast it was having it working with U9.6 and expecially considering the U9.7 usys.ini file was edited and saved with Windows user "Gianni" having normal privileges of standard users. The renewed access control from Microsoft in latest Windows versions (from 8 on) and its relation with applications has still some black corner for me to be discovered... Anyhow thanks again...[Solved] Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  3. You're welcome Gianni! Daniel did some explaining on this Windows behaviour in the topic on the missing Debugger buttons as well.


    Author: Arjen van Vliet (arjen.van.vliet@uniface.com)
  4. gianni said Thanks Arjen! "Run As Administrator" did the trick... I do not understand why administrative privileges are involved considering how fast it was having it working with U9.6 and expecially considering the U9.7 usys.ini file was edited and saved with Windows user "Gianni" having normal privileges of standard users. The renewed access control from Microsoft in latest Windows versions (from 8 on) and its relation with applications has still some black corner for me to be discovered... Anyhow thanks again...[Solved] Gianni

    My theory here is slightly different: some action probably caused that the IDF updated the usys.ini and hereby creating a "copy" of the file in the VirtualStore of your user profile. After that you've changed the usys.ini in the "original" location (e.g. \Uniface\adm\usys.ini). When the "normal" user will now start the IDF he will see the content of the usys.ini "copy" (in the VirtualStore). And when the IDF is started with elevated rights (e.g. Run as Admin) then you'll see the content of the "original" usys.ini. In order to avoid any future confusion it might be a good idea to delete the files in the VirtualStore. You should find the files here:

    • C:\Users\{UserName}\AppData\Local\VirtualStore\Program Files (x86)\Uniface

    Under the assumption that you've installed Uniface in the default location (i.e. C:\Program Files (x86)\Uniface). The problem could actually be "avoided" if the internal manifest of the uniface executables (e.g. idf.exe) would feature the following:

    <trustInfo xmlns=”urn:schemas-microsoft-com:asm.v3″>     <security>         <requestedPrivileges>             <requestedExecutionLevel level=”asInvoker” uiAccess=”false”/>         </requestedPrivileges>     </security> </trustInfo> More info about this can be found (e.g.) here. Now any update of the usys.ini (and in fact any file that is located in a protected Windows directory, like e.g. 'Program Files (x86)') would fail (and nothing is written to the VirtualStore). But this might cause other "inconveniences". Hope this helps. Daniel


    Author: diseli (daniel.iseli@uniface.com)
  5. Daniel,

    It's a kind of magic One shaft of light that shows the way It's a kind of magic You've hit the center: a copy of the old usys.ini was saved in my virtual store. It will be nice if the additional manifest rule will be included in the next maintenance releases to reduce headaches to Unifacers. Definitively [SOLVED]. Thanks! Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)