CDR Tickets

I received this question from Diana, too. Here is what worked for me to some degree.

1. Click the Start button

2. Right-click on IE and select Properties

3. Click the Shortcut tab

4. Next to the Run field there is a drop-down menu: Select Maximized or Normal Window

5. Close the Properties window

Now close IE and try to open the report again.

I've been running QC reports this morning and noticed that IE starts in the foreground for me.
Did anything change for other users, too by any chance?

Unfortunately, it's still opening in the background for me.

I'm back at searching for solutions to this problem again.

Does IE always open in the background? For me IE opens the first window in the background but if IE is already running, the following window does open in the foreground and all successively opened windows. This only happens when windows are opened from within XMetaL.Submitting the same command/URL from a *.bat file opens the window as expected in the foreground.

~bkline, do you think it's possible that the macro to open IE submits the command but returns the focus back to XMetaL before the IE window opened and therefore stays in the background? Of course, that wouldn't explain why a second attempt to open a QC report would work properly.
Maybe it's possible to identify if IE is already started and start a bogus or empty window first before submitting the URL with the QC/PP report.

I did adjust two Registry entries for my workstation. These modified settings for

HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundFlashCount

and

HKEY_CURRENT_USER\Control Panel\Desktop\ ForegroundLockTimeout

It's always in the background for me, regardless of whether I already have IE open.

OK, in this case I suggest we'll submit a ticket to CBIIT to have your registry settings adjusted. Maybe those settings are making the problem a little less painful.

I will reset the registry on my computer and try again but I'll have to restart my system for the settings to take effect, so I won't be doing this right away.

do you think it's possible that the macro to open IE submits the command but returns the focus back to XMetaL before the IE window opened and therefore stays in the background?

Not a bad question. Anything's possible, but I have no idea how I would go about getting a reliable answer to the underlying question (i.e., whether that what's really happening).

Maybe it's possible to identify if IE is already started and start a bogus or empty window first before submitting the URL with the QC/PP report.

I don't know of a reliable way to determine whether IE is already started, and even if there were a way, this seems like more of a kludge than what we've got now.

I've done some more research, and I've got another approach implemented on DEV. It's more straightforward, and seems to always open IE in the foreground. It creates a new window each time IE is launched from XMetaL, which could be a good thing or a bad thing, depending on your point of view. If the users find that this works better for them, we'll need to test thoroughly with lots of different user machines (and of course this is a release-dependent change). Please give it a try.

Are you now starting a *.bat file from XMetaL which in turn is starting IE rather than starting IE from within the C++ code? I had that on my list of things to try as well.

Anyway, my very limited tests - starting a few QC reports - seem to do the right thing. With your solution IE always opened in the foreground.

Are you now starting a *.bat file from XMetaL ...?

I'm using the standard library's system() function, which invokes the command processor (cmd.exe on Windows).

This works pretty well so far. A smaller black command window opens before IE gets launched, but as far as I can tell that window closes itself (rather than stacking up and requiring me to close it later). Is that right? If so, I think we can live with the temporary flash of the command window.

On an unrelated note, I'm also optimistic that we may have found a solution to the "switch to" error - I haven't seen it yet while testing this on DEV....fingers crossed.

... we may have found a solution to the "switch to" error ...

Wouldn't that be sweet? :-)

This was fixed together with OCECDR-4117. Verified on PROD.