Upgrade Uniface 9.4 to Uniface 9.6.

Author: sergio_enbe@hotmail.com (Sergio Encinas Benítez)

We're planning to upgrade this month (July 2013) our version of Uniface from 9.4.01.01 (0302_2) to 9.6. We want to know some advices for us to be prepared for the migration of the forms, reports, etc. We currently have the UDE for Windows XP (1GB RAM 32 BITS) and now we're going to install 9.6 in Windows 7 (16GB RAM 64 BITS). We also use Citrix Server and our DBMS is Sybase 15.0.3. Thank you Laugh

8 Comments

  1. I don't remember right know any important problem. Just if you have an ASN file with several ASN files included (#file directive) and several of them have definitions for the LOGICALS section, AND if the same logical name is defined in different files, Uniface does not start nor notify you the problem.


    Author: luis.vila (luis.vila@uniface.es)
  2. Hello, we've migrated from U93 to U95 some time ago. I can't remember of any serious issue with this. This month we've migrated from U95 to U96. Very similar process. I think migration from U94 to U96 should be quite easy. As for database, we use Oracle only - and with U96, only Oracle 11 is supported, no earlier version. You should check support for your database (Sybase?) in Uniface 9.6. Also... we have several serious problems with GUI in Uniface 9.6.02. The latest patch X201 does not solve anything. We were forced to downgrade to Uniface 9.6.01 and we are currently on Uniface 9.6.01 + patch X104. Based on my communication with technical support, it seems we will be using this patch for a long time. But all these bugs in GUI in Uniface 9.6.02 are in some specific situations, so if you do not use the Uniface as we use it, it might be that these bugs won't influence you. And Uniface 9.6.02 includes some really great GUI improvements (we are going to use them ASAP). And last but not least warning, Uniface 9.6.02 changes behaviour of form positioning during runtime (but not during development). This is quite strange change, you might like it or not. You can restore the old behaviour by setting FormPositionFromInside=On in your .ini file. Good luck with migration Cool, Zdeněk Socha


    Author: sochaz (zdenek.socha@fullsys.cz)
  3. Hi Zdeněk, can you give us some hint in which area the GUI problems are located? Because it looks like one has to go to 9.6.02 to use some of the "new in 9.6. features".


    Author: ulrich-merkel (ulrichmerkel@web.de)
  4. The most important for us: - changing a text of a label associated to a checkbox changes the font to a bigger one (changing value of the checkbox seems to fix it) - setting a tooltiptext on an editbox removes all colors from the editbox making it white (all colors seem to be removed, be it set via fieldvideo, curoccivdeo or during development) The latter is much worse for us, because we use curoccvideo in almost all forms and fieldvideo is used to help navigate our application (fields with colors have some special funcionality). We need multilingual application, so we change every text on a form and set tooltips for all fields during initialization of a form - and this process removes all colors from all fields (editboxes). Cry Some editboxes are gray to looks like labels - these are made white. AFAIK there is no workaround for this. I think, if you do not touch labeltexts and tooltips, you might be safed (from these bugs). Wink


    Author: sochaz (zdenek.socha@fullsys.cz)
  5. Thank you Zdeněk, at least it's good to know what one (and ones customers) will face with the current 9.6.02. So you have to make a choice to turn down user support (tooltips, multilingual user interface) and living with the 9.6.01 problems a bit longer. Reminds me on a situation I had with (I think) Uniface 7 where all of the sudden $page below 10 were not printed. The question was: shouln't they (CPWR) have found that at least during acceptance tests at first glance?


    Author: ulrich-merkel (ulrichmerkel@web.de)
  6. Hi Zdenek, 1) Using 9.6.02 this works for me for the checkbox: $fieldproperties("CB1","labelfont") = "labelfont=SampleMenu1" $labelproperties("CB1") = "text=New Label" Are you using the same sytax? 2) And this goes well with the editbox: $fieldproperties("CB1","tooltiptext") = "tooltiptext=Hello world" Are you using the same syntax? 3) Gray editboxes that become white: Can't reproduce that quickly either. But setting inheritcolor to true instead of making them gray should be a workaround. Also much nicer is you later decide to change the backgound of your forms to light blue instead of gray. I hope you have reported these issues, then they will come to my team soon so we can fix them. Regards, Theo Neeskens


    Author: Theo Neeskens (tneeskens@itblockz.nl)
  7. Hello Theo, 1) no, we use different proc code.. something like this: (V_TMP and V_POLE_ENT are string variables) show getitem/id V_TMP, $labelproperties(V_POLE_ENT), "text" putitem/id $labelproperties(V_POLE_ENT), "text", V_TMP edit 2) again, we use something like this: show getitem/id V_TMP, $properties(V_POLE_ENT), "ToolTipText" putitem/id $properties(V_POLE_ENT), "ToolTipText", V_TMP edit 3) I think the same syntax from 2) influence this we have more than 3000 components, it's not a simple task to find and change some editboxes just as workaround... we will wait for a fix. I have created a support case for this on May 31 following some discussion and testsets and so on with the support team. And there is already a registered bug "Bug 30258 - First display label from a checkbox is corrupt when certain proc is used." (you should see this bug, right?), which is planned to be fixed in X202. If you can see my support case, you can find there testset and screenshots (taken on Windows 7 64bit with aero). Regards, Zdeněk


    Author: sochaz (zdenek.socha@fullsys.cz)
  8. Hi Zdenek, Just recieved the request to estimate the fixing effort for this. Based on that and the priority of the bug Support will decide in what patch we can put it. At least I know who to contact if we have more detailed questions Wink Theo


    Author: Theo Neeskens (tneeskens@itblockz.nl)