- This topic has 16 replies, 6 voices, and was last updated 19 years, 1 month ago by
.
-
Topic
-
Theer seems to be a problem with GUI locks. Unless you exit the qui with the tab (right click), the lock does not get removed. theer are three way to exit the gui – the tab, the file->exit or the X on the ide – all should free any locks that may have been present. Anyone else feel like this reasonable ?
-
Replies
-
-
Yes, I agree. This is the reason we have chosen not to go live on version 5.2.1. In our development environment, the gui’s have caused netconfig corruptions (several times) and have kept smat files open so they are rendered unusable. We hadn’t figured out yet that this was all caused when not closing via the tab. That will certainly be helpful in the future. Hopefully these issues will be fixed in 5.3; this is too big of a risk to have in our live environment.
-
I couldn’t agree more. Since there is obviously a method that responds to a FILE_CLOSE event, it seems like there needs to be a window listener that will call that method when a windowClosing event is registered. In other words, the code should already be there to address this, it just needs to be issued in a patch. I have seen this problem since 3.8 and in some events in 3.7.1 and I don’t understand why it hasn’t been addressed. -
-
I would also like to see several other things: 1.
A NetConfig that is a directory with config files in it — I have mentioned this before but I would like to see the information for each process in a separate file and the information for each protocol thread in a separate file. This would allow greater automation in the development and maintenance of interfaces. It might even be nice to have the route/xlate information in a separate file.
Why, you ask….well, there are several reasons, you could then add a new thread by added it to the NetConfig directory, the GUI could load only the files that you needed…the list goes on and on. It might even be better to have the NetConfig be a hierarchical structure vis-a-vis the HL7 or XML format directory structures.
2.
Make the configuration tools capable of editing local files instead of requiring a connection to the server. Yeah, I know, managing the issues related to two developers modifying the same sight at the same time would be difficult (unless the NetConfig were a directory structure…see above). It would be much better, though, to be able to use the GUI’s (and maybe the testing tool) directly within a client machine. The development of interfaces would go much quicker and easier. The only benefit to requiring the server connection is that it keeps me (us) from doing much development after hours. Whether this is a benefit or not certainly depends on who you ask…
Well, that is all that I have the energy for tonight…LOL
-
I think that Quovadx is working on a native windows executable for the guis. This will replace the Java client, and all the Java weirdness that accompanies it. (Wheel scroll, sorting of items in dialogs, etc.) You may also want to distill your suggestions and place them in the “Product Enhancement” area of the board. That will make them easy for Quovadx to find and evaluate.
-
-
I won’t mourn the Java GUI’s passing … but I do mourn the TCL/TK GUI’s passing. Seems to me Java has always been much better for the server end. The only problem with using a native-Windows GUI is that it’s only good for Windows clients. a) Some people use … and prefer … Linux or Unix workstations
b) You’ll never be able to run the Windows GUI on the Cloverleaf box in a pinch …. unless you’re running Cloverleaf on Windows
c) Personally, I prefer a long-running GUI on the Cloverleaf system that I (or someone else) can access by VNC from home or work, whether to change anything or just to monitor the interfaces. Of course, I already avoid the Java GUI in favor of the old “Network Monitor”, since the Java GUI is not recommended to be run on the Cloverleaf server if you’re on AIX. But with a Windows client it will not only be “not recommended”, but also, “not possible”.
Granted, the old TCL/TK GUI’s were dated. But then, they were old. The Java GUI was better organized and better appearing, but seemed to lose some functionality and be noticeably slower. And not very VNC-friendly, since it seemed to spend so much of its time redrawing itself.
It’s very possible to make TK gui’s look modern and be functional, with probably less effort still than most tookits. And you get a cross-platform GUI in the bargain. And since TK uses native components where possible, it would still look like a pure-native Windows GUI.
Besides, using the new “Starkit” functionality available in TCL now, client installation could be reduced to copying two files to the client and setting up a shortcut.
Strange that I would argue for TCL/TK, since it’s only because of Cloverleaf that I ever learned TCL ….
😕 -
That is one specific feature that I asked about at the user conference. I think that it’s important that the GUIs should run in one of the standard Linux emulation packages (WINE, Crossover Office, etc.) as suggested by Rob Abbott. Linux is an option that fast becoming a worthy, lower cost option for those who don’t mind taking a hands-on approach. -
-
-
What have you got against guinea pigs? They are kinda cute after all. At any rate, I cannot say that I have seen any major projects that have been cross platform compiled with .NET. But, then again, I have to admit that I have not really researched it. That said, I think that, perhaps, a web-based solution to the presentation layer may be the way to go. Or, more to the point, several different options for presentation would be good — don’t like java, use TK — don’t like Tk, use a browser. If the other layers in the hierarchy are coded correctly, the particulars of the presentation should not be a problem…
Also with reference to the guinea pig — it wouldn’t be the first time…LOL
-
now we have had a number of things mentioned. tk net mono java web, but only one is really universal, if the pages are written without any microsoft/netscape/mozilla/firefox/etc specific extensions, then the web browser would be the one of choice for me. mix and match your os’es (aix, sun, ms, linux, beos, you name it, even some organizers have web browsers, even telephones – these latter are quite limited in their displays, but…), all have a web browser. You would even be able to do the cloverleaf guis on an apple as it will not be tied to any single os or browser. Run the browser on your server with an X display to your pc if your want (does require your pc to be running an xserver but it works well). And all the traffic can easily be SSL. Automatically meets most security policies.
If quovadx wants to write code that runs on multiple platforms (most) and maintain the same on each platform, that
-
P.S to the last post I have implements a mini browser in TCl that allows me view the status, files, etc. across the engines in our multiple sites.
for instance – paweb pages and selections – they don’t show well here but if anyone wants to see the pages, I’ll send them a word pages to interrested parties – follow below please.
THE FIRST PAGE- initial selections
svclov:/qvdx/quovadx/qdx5.2/integrator/charges_p –
Fri Mar 18 08:51:09 CST 2005
Site Configuration
Site Assigned TCPIP Ports
Connection Status
Process status
Recovery Database by SRC/DST Thread
Message count of the recovery database
RDB count by connection
Error Database by SRC/DST Thread
Message count of the error database
EDB count by connection
Paging Control
Pages
Scheduler file
Alerts
Top
AIX vmstat (allow 30 sec for output)
AIX iostat (allow 30 sec for output)
AIX df command
Thread status selection
Thread Display
Thread Display – 2 wide
Expanded Thread Display – 2 wide
Thread Display – pxqued
AIX ipcs command
Site Documentation
AIM Que Monitor Display
All sites monitor
SELECT thread status selection ( quick summary of all threads – 2nd number is qued msgs))
svclov:/qvdx/quovadx/qdx5.2/integrator/charges_p – status
Fri Mar 18 12:14:30 CST 2005
as_copath_c up 0
as_lab_c up 0
as_medi_c up 0
as_pat_coal up 0
as_to_pat up 0
bhv_medi_c up 0
bir_mlink_c up 0
bir_omnis_c up 0
bir_pat_coal up 0
bir_pxmed_c up 0
bir_pxsup_c up 0
bir_to_pat up 0
bsh_omnis_c up 0
bsh_pxsup_c up 0
bu_bcon_c up 0
bu_ipath_c up 0
bu_omnis_c up 0
bu_pat_coal up 0
bu_pharm_c up 0
bu_pxsuped_c up
Select one of these ( red or green box shows at the left of each on on the browser)
and you get detailed status (all on you web browser-)
svclov:/qvdx/quovadx/qdx5.2/integrator/charges_p – status fr_as_oe_c
Fri Mar 18 12:16:19 CST 2005
proto status = opening
Thread Data Section for: fr_as_oe_c
Scn Addr : 0x40065320
Scn Version : 1
Scn Updated : Tue Mar 1 08:53:07 2005
Sample Taken : Fri Mar 18 12:16:19 2005
Sample Added : Fri Mar 18 12:16:20 2005
Start Time : Tue Mar 1 08:53:07 2005
Stop Time : never
Proto Status : 1
Proto Flags : 0
Proto Last Rd : Fri Mar 18 00:20:10 2005
Proto Last Wt : Fri Mar 18 00:20:10 2005
Proto Err Time: never
Proto Err Msg :
Xlate Count : 64246
Forward Count : 0
Error Count : 0
IB Latency : 10286.743
OB Latency : 2303.043
Total Latency : 2303.370
Msgs In : 64246
Msgs Out : 64246
Bytes In : 19097640
Bytes Out : 5567190
IB Pre-SMS QD : 0
IB Post-SMS QD: 0
OB Pre-SMS QD : 0
OB Data QD : 0
OB Reply QD : 0
Pre-Xlate QD : 0
Inter-thread Statistics
Sent Recvd pxqd X time T on Q Latency Thread name
—-
0 0 0 0.000 0.000 0.000 bu_sscan_c
0 0 0 0.000 0.000 0.000 bhv_medi_c
0 0 0 0.000 0.000 0.000 bu_pharm_c
0 0 0 0.000 0.000 0.000 bu_pxsuped_c
0 0 0 0.000 0.000 0.000 pl_ipath_c
0 0 0 0.000 0.000 0.000 fr_pl_rad_c
0 0 0 0.000 0.000 0.000 gar_worx_c
0 0 0 0.000 0.000 0.000 fr_bu_radkt_c
0 0 0 0.000 0.000 0.000 fr_bu_pxsuped_c
0 0 0 0.000 0.000 0.000 gar_to_pat
0 0 0 0.000 0.000 0.000 fr_bir_pxmed_c
0 0 0 0.000 0.000 0.000 as_copath_c
0 0 0 0.000 0.000 0.000 bu_ipath_c
0 0 0 0.000 0.000 0.000 pl_pat_coal
0 0 0 0.000 0.000 0.000 as_pat_coal
0 0 0 0.000 0.000 0.000 scheduler
0 0 0 0.000 0.000 0.000 fr_pl_omni_c
0 0 0 0.000 0.000 0.000 fr_pl_ecl_c
0 0 0 0.000 0.000 0.000 fr_bu_bcon_c
0 0 0 0.000 0.000 0.000 bir_mlink_c
0 0 0 0.000 0.000 0.000 gar_rad_c
0 0 0 0.000 0.000 0.000 gar_pat_coal
0 0 0 0.000 0.000 0.000 bu_to_pat
0 0 0 0.000 0.000 0.000 fr_bu_radmc_c
0 0 0 0.000 0.000 0.000 fr_bhv_medi_c
0 0 0 0.000 0.000 0.000 fr_bu_pharm_c
0 0 0 0.000 0.000 0.000 fr_bu_sscan_c
0 0 0 0.000 0.000 0.000 fr_grp_rad_c
0 0 0 0.000 0.000 0.000 cmc_to_pat
0 0 0 0.000 0.000 0.000 fr_gar_worx_c
0 0 0 0.000 0.000 0.000 fr_pl_ipath_c
0 0 0 0.000 0.000 0.000 fr_as_copath_c
0 0 0 0.000 0.000 0.000 fr_as_lab_c
0 0 0 0.000 0.000 0.000 fr_pl_lab_c
0 0 0 0.000 0.000 0.000 pl_rad_c
64246 0 0 646.610 0.000 0.000 as_medi_c
0 0 0 0.000 0.000 0.000 pl_worx_c
0 0 0 0.000 0.000 0.000 ell_rad_c
0 0 0 0.000 0.000 0.000 bir_pxsup_c
…
-
-
-
I do see those but it doesn’t close the GUI, just the particular module you have open. We often see locks made by each other and ourselves and we do close things from the tabs then exit the program using file- exit. The original post said three ways to close the GUI and I was just wondering if there was something else I had missed. Thanks though.
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
