The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

odd Hyperlink issues

Our company has developed an app in WTL, which we have already distributed to our customers and which has worked fine on many different systems. However, all of a sudden, I realised that it is only on my computer that an odd problem occurs. The details:

* We use CHyperLink throughout the desktop app to launch into various web-site pages.
* In initialization we call CHyperLink::SetHyperLink to call a URL, such as '".
* On almost all machines, clicking on the hyperlink pops up IE, except on my machine were nothing appears to be happening.
* Unfortuntely I cannot debug on this machine (and trace through the possible errors) due to various reasons.

Now I am stumped as to why this error occurs, and cannot see how such a simple piece of code could fail. My only guess is that it has to do either with the fact that I have FireFox on my PC, or that it is WinXP SP2 and has some sort of security that stops an app from popping up a browser.

If someone can help, then it would be appreciated. If not, then is anyone aware of a possible more advanced hyperlink control we could use. In fact, if you know of a WTL hyperlink control that also allows you to put a small icon next to the text, it would be a bonus for me.
Friday, January 14, 2005
Could be something to do with firefox. I have some weird problems sometimes when programs try to launch hyperlinks, though mine take the form of two copies of firefox being loaded, neither with anything in the page, and one being resized to about one-and-a-half desktops' width. (This problem seems to be somewhat random, so it's quite possibly not directly relevant, but clearly IE, as you might expect, integrates with windows slightly better than firefox.)

But anyway. I'd be inclined to get it so the program can be debugged first, in order to avoid the need for random shots in the dark. Helpful, eh? But I mention this because, in the absence of a debugger, I've found OutputDebugString combined with sysinternals' dbgviewer to be very helpful.


SysInternals' dbgviewer:
Sunday, January 16, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz