All posts by gypsilon

uniface Manifest free

We need a manifest-free uniface.exe, t.i. a uniface.exe with an external uniface.exe.manifest

Background:
Based on the topic \\\”reg-free .NET COM with uniface on windows 7\\\”, we enhanced the internal Manifest of uniface.exe.
As a result, we are reg-free, there is no need to do any local registration of our enhancements.
Sometimes we need an update of our functionality and we need an update of the Manifest within uniface.exe.
So we take uniface.exe and with \\\”mt\\\” we are changing the entries within the manifest.

As long as uniface.exe (on production) is in use, you cannot replace the exe File. Since our application works 24h a day, there is no real chance update uniface.exe with an actual enhanced manifest.
Is it possible to publish a uniface.exe without manifest (and all the signs etc) and a separate uniface.exe.Manifest? So that we just can use the separate Manifest file by replacing it during an update?
This is really helpful, and could reduce some already reported error situations.

urouter issues

1.
The information in the urouter.log-Files is cryptic. Abbreviations are inconsistent (srvid – sid), and hard to understand.
Numbers and time-counting. I\’ve got the feeling that the time-Information in the urouter-log is not very precise or in sync with the \”real time\”.
It is impossible to reconstruct a situation out of the log-files, e.g. Finding common entries between urouter-log and corresponding userver-log files.
No common \”time-counting\”. (we\’ve got lots of userver-logs). To grep or awk throught the log is nearly impossible. Information spreaded and line-breaks… makes it more difficult for an automatied analysis.
And there is zero description in the helpfiles concerning the log-Information of the urouter. It can be cryptic, no problem, but it must be coherent, and \”easy to analyse\” (e.h. grep or awk).

2.
UROUTMON. Just a nice idea. If I want to start the UROUTMON, just to get a view what happens, I sometimes (depend on the place where i work) get some license issues. I possibly can\’t consume a customer license-File just to have a look on the UROUTMON what is going on. To hack around is not always a good idea. For LIVE not useable! Please make the uroutmon \”license free\”. It is a nice tool, but it shouldn\’t search or consume any licenses.

3.
UST. We\’ve got on one urouter lots of uservers, with lots of different usts, because we need to communicate different databases and in different \”context\”. Currently there are somewhat of 100 UST-entries in the urouter.asn. It is really horrible to maintain the list.
It could be nice to define a kind of \”dynamic\” UST where I can tell, if the UST has a specific format then the parameters should follow that \”format\”.
Something like (e.g.) xxx-z-yyy userver.exe /asn=xxx.asn /maxidle=z /ini=yyy.ini /…whatever…
BTW. We are generating the asn-File (for the application and userver!) dynamic, so that this kind of ruling the UST would fit perfectly in our concepts.

uniface Defaultkeys

$fieldproperties(HTML)=\”UnifaceKeys=defaultkeys\”
is normally to redirect a collcetion of Keys to uniface rather to the widget. (e.g. CTRL-R = Retrieve and not interpreted by the html-Widget).
Since CTRL-C is something which I do not want to redirect to uniface, the defaultkeys doesn\’t make sense in most of the practical cases, where I need an html-Widget in uniface.
So I will get a very big list of Keys, which should be redirected instead of \”defaultkeys\”.

And if someone enhance e.g. the Accelerator List in the ini-File, don\’t forget to enhance the UnifaceKeys of your widget!
That is not practical. There is a need to make life easier, e.g. to exclude a couple of Keys out from the DefaultKey Setting, or defining a kind of negative list (all should be handled by uniface except: CTRL-C, CTRL-V ….) Or some Kind of additional Groups (like: DefaultKeysExceptCopy.), or Define the Defaultkeys – List once somewhere in an ini or asn-File setting. I don\’t mind, but I don\’t want to define a huge list within the code.

Field layout issues

\\\”Some issues on Field layout can be simplified. This wish is NOT to be intended an \\\”\\\”international issue\\\”\\\” in terms of how to define the Layout depending on a Language. This is maybe worth another wish or a discussion threat. There are several situations in our application and projects, where we need enhanced features of the \\\”\\\”Field Layout Definition\\\”\\\”. (1) Layout-Definition at runtime – The layout of a field within a Grid needs to be adapted. Since our user can choose some additional information to display, they can be either numeric or Text-information. Depending on the content we want to display this information right-aligned or left-aligned. This decision can be done only at runtime. For this kind of issue we need within a grid the possibility to display the data in the desired Layout definition. – There are possibly some \\\”\\\”old needs\\\”\\\” coming from version 7. To get the data correct formatted we did insert a couple of spaces. As long as the field size and the font were fixed, it did run. Using grid-widgets and different fonts, we need a way to get fields right-aligned in runtime. – Statements like $layout and $fieldlayout can be very useful. (2) A changeable layout-Definition on Field-level in Services. The second situation is in Services. The uniface-developers thought \\\”\\\”Field layout\\\”\\\” is not necessary for services, so they greyed them out! (since V8). This is definitly wrong. If you try to build an XML-stream (in a service) or prepare the fields for another output, the \\\”\\\”Layout\\\”\\\”-Definition becomes important! If there is another layout-definition in the model, you cannot change the layout on external level in services (in an official way)! Please OPEN the Layout definition of fields in all kind of services! Alternatively (based on (1)) : Give us a possibility to change the layout definition at run-time (even for services).\\\”