Hi Peter,

Thanks for your reply, and sorry for my late response.

I agree that these issues are not impairing the real functionality of Mercury/32 in any way, but it would be nice when the change of development environment would cure them.

If I can help in any way by testing something, just let me know.

Regards, Ed

Hi,

Using Mercury32 for some years now, I am

very happy with it.

However, there are two small GUI related

problems that I would like to address:

1) Mercury32 is installed as a service

under Windows XP, using srvany. When logging in locally on the PC, everything is

looking OK.

But when logging in through the WinXP

remote desktop client there are some issues. The lower part of the main window

is blanked; so the Licensing text is gone. And when I drag the lower edge of

the main window upwards for a small amount, the same lower part of the windows

suddenly grows such that half of the main window is occupied with it. When this

has happened, it only can be corrected by restarting the service, after which

the Licensing text is shown correctly as well (until the next login).

2) When the main Mercury32 window is

minimised to the task bar, it can be called back by double clicking on the

icon. However, when there is another icon on the left of the Mercury32 icon,

and the Mercury32 icon is double-clicked, both the Mercury32 window and the

other applications window are opened.

This happens both when logging in locally

or via the remote desktop client.

Can someone else please confirm these

problems?

If the description is unclear, I can make

some screen grabs when required.

Thanks,

Ed

I can't confirm the first.  I am running Mercury/32 as a service using NT Wrapper Pro and it works as specified. However I'm using VNC for remote access and not the remote desktop client.  Looks like a problem with the remote desktop client.

The second one I can confirm and the action depends on whether the adjacent application open with a single or double click.  For example I currently have Servers Alive (double click to open) running next to Mercury/32 and the double click only opens Mercury/32.  When Editpad (single click to open) is next to Mercury/32 then both Mercury/32 and Editpad open.  This is just another one of the "features" of the MS Win32 operating system.  ;-)

Hi Thomas,

Thanks for your reply.

Regarding the first problem: no, this does not happen with VNC. However, I prefer to use the remote desktop client, because it performs much better then VNC, especially when using a slow connection (like a VPN over the Internet). It is a problem specifically with the remote desktop connection, but might be the same with a (related) full-blown Terminal Services connection, although I cannot confirm this. But I think Mercury32 not fully complying with the Windows GUI requirements causes the problem.

 Regarding the second problem: thanks for the confirmation. This can be seen as a "feature" of the Win32 OS, but again I think that Mercury32 not fully complying with the Windows GUI requirements causes it.

So I hope that the Mercury team can resolve these issues.

[quote user="kwikzilver"]

Hi Thomas,

Thanks for your reply.

Regarding the first problem: no, this does not happen with VNC. However, I prefer to use the remote desktop client, because it performs much better then VNC, especially when using a slow connection (like a VPN over the Internet). It is a problem specifically with the remote desktop connection, but might be the same with a (related) full-blown Terminal Services connection, although I cannot confirm this. But I think Mercury32 not fully complying with the Windows GUI requirements causes the problem.

 Regarding the second problem: thanks for the confirmation. This can be seen as a "feature" of the Win32 OS, but again I think that Mercury32 not fully complying with the Windows GUI requirements causes it.

So I hope that the Mercury team can resolve these issues.

[/quote]

Sorry I have to disagree in both cases, Mercury/32 is in full compliance with the requirements.  These are both problem where the people writing there system assumed something would happen when it does not. 

The remote client is probably assuming that the GUI application runs in a specified manner not actually required by the windows interface.  Since it does not happen either directly or with VNC it's obvious that the remote client  has problems with it's assumptions. 

As for the the second if Mercury/32 were a singe click application then suspect this would not happen.  This is not a requirement of the OS.  The problem is that the OS is feeding the second click to the adjacent single click application not that Mercury/32 is a double click application.

The fix is required at the remote client and OS level, not Mercury/32.   Lots of luck getting MS to respond to these long term issues.  ;-)

Well, it looks like we will not reach an agreement about this.
For both cases I know a lot of applications that are not behaving like this under the same circumstances. Many applications respond on double-clicks on their taskbar icon by re-opening their window, without adjacent programs following. Mercury32 is the only program that I know that is behaving like this. And the same counts for the remote desktop client problem.
I am not a programmer, but I am pretty sure that when the makers of Mercury32 are looking into this, they will find the cause and a solution for it.

Agreed, we will not reach agreement.  Mercury/32 is using the Borland C complier and I've other double click applications that cause the same affect with the adjacent single click apps.  David is moving to the Visual C++ compiler, closed beta WinPMail v4.5 is using it now, and maybe this will change how MS Win32 handles the double click.

[quote user="kwikzilver"] But when logging in through the WinXP remote desktop client there are some issues. The lower part of the main window is blanked; <snip>[/quote]

Yes confirmed, there are a number of issues with Mercury/32 administration over RDP, screen resolutions, color depths, and client versions seem to matter. Doesn't matter much if it is XP, Srvr2003, or Srvr2008. It has nothing to do with the install being a service. However, the problems are not consistent and I haven't tried to track them all down. It also seems that you have some slight different blanking problems that I see. However, resizing any module window, or resizing Mercury/32 app, makes them behave as expected. So I can only assume that the Borland dictionary for windows calls that David uses now is slightly outdated, and that this should fix itself as soon as David changes development environment. The functionality of Mercury/32 has never been compromised by the graphic RDP troubles though.

<?xml:namespace prefix = o />

[quote user="kwikzilver"]

Yes confirmed. You can in a RDP /console session notice the following: if you have installed language switching when you hover the Mercury icon just right of the language icon, also the language switch app is selected (since it is lowered). This means that both apps get the double click - and yes - it is quite annoying - but also something that doesn't impair the functionality of Mercury/32. I haven't reflected much about why this happens, and it only happens when there is only one Mercury icon left.

Another issue is that Mercury self-minimizes when you leave a RDP /console session. Now this is not annoying, but "odd".