0

Edit: More Information I've narrowed it down to certain applications on certain computers. I am trying to launch chrome in a full screen mode on a certain monitor. This works perfectly on most systems I have tested however we have run into a set of computers running Windows 7 Pro 32bit which are being moved and resized correctly, but their border and buttons are still intact.

I realize that chrome windows all spawn under a single chrome process and that their lifecycle is volatile, but we have been able to work around this using a separate data directory which keeps each chrome instance launched that way in it's own parent process. Chrome seems to be the only application we have problems launching full screen and only on one set of computers. When running calc.exe for instance it maximizes and removes the borders without any problems on all systems we have tested. I have confirmed that the version of chrome running on each system is the same. I would really appreciate it if anyone had more insight into either this problem, or ways of further troubleshooting the issue.

I'm trying to run an application in a full screen mode using SetWindowLong and it's worked great up until the latest computer I tried it on. I am basically using the code referenced in this question: Removing window border?

This works fine on both of my laptops (Windows 7 Ultimate) and a couple work boxes that I have tested it on (Windows 7 POS Embedded) but it's not working on another computer at work (Windows 7 Professional). The SetWindowLong call is returning the expected value which indicates to me that it should be working, and the call to SetWindowPos works fine as it's resizing the window correctly, but the border and buttons are still there! It's functioning as if there was no call to SetWindowLong at all. I would greatly appreciate some help as I'm out of ideas at this point.

Edit: Here is the code in all it's 1AM red eyed glory. Pretty much a direct copy of the linked question.

int lStyle = GetWindowLong(process.MainWindowHandle, GWL_STYLE);
lStyle &= ~(WS_CAPTION | WS_THICKFRAME | WS_MINIMIZE | WS_MAXIMIZE | WS_SYSMENU);
_logger.Debug(String.Format("Style: {0}", lStyle)); // 369295360

var swlResult = SetWindowLong(process.MainWindowHandle, GWL_STYLE, lStyle);
_logger.Debug(String.Format("SetWindowLong: {0}", swlResult)); // 382664704

int lExStyle = GetWindowLong(process.MainWindowHandle, GWL_EXSTYLE);

lExStyle &= ~(WS_EX_DLGMODALFRAME | WS_EX_CLIENTEDGE | WS_EX_STATICEDGE);
SetWindowLong(process.MainWindowHandle, GWL_EXSTYLE, lExStyle);

Screen screen = GetDisplay(display);

return SetWindowPos(
    process.MainWindowHandle,
    HWND_TOPMOST,
    screen.WorkingArea.Left,
    screen.WorkingArea.Top,
    screen.WorkingArea.Width,
    screen.WorkingArea.Height,
    SetWindowPosFlags.SWP_FRAMECHANGED);
Community
  • 1
  • 1
Timothy Strimple
  • 22,920
  • 6
  • 69
  • 76
  • You are using Winforms. Just set the FormBorderStyle property to None. – Hans Passant Nov 05 '11 at 09:54
  • I am not using windows forms. I am using the Process class to start a 3rd party app and I am trying to run it fullscreen without borders. – Timothy Strimple Nov 05 '11 at 15:40
  • Are you sure you have the right HWND? Is it possible that your app and your target app have different integrity levels, preventing your access to their window? – Gabe Nov 06 '11 at 05:46
  • I'm pretty certain it's the correct HWND. I start the process using Process.Start and grab the HWND from that, and the SetWindowPos call seems to work as the windows go to the right place and resize correctly. If it was a permissions problem, wouldn't the resize and position also fail? – Timothy Strimple Nov 06 '11 at 05:53

2 Answers2

1

Found the problem. We are using LogMeIn for remote computer management, and it seems like their video mirror driver is causing problems on certain machines. Uninstalling their mirror driver, and restarting causes everything to work as expected.

It is also the case that this fails with out-of-date copies of XP (even SP3, and perhaps others). I have confirmed on over a dozen workstations that installing recommended updates resolves this issue. There were an average of updates needed on each, so it's hard to say which one did the trick, but apparently one of them did. Yet another reason to keep updates enabled.

mostlydev
  • 715
  • 6
  • 16
Timothy Strimple
  • 22,920
  • 6
  • 69
  • 76
0

Is the Windows 7 Professional system 64 bit? According to the documentation for SetWindowLong

This function has been superseded by the SetWindowLongPtr function. To write code that is compatible with both 32-bit and 64-bit versions of Windows, use the SetWindowLongPtr function.

Try modifying your code to call the SetWindowLongPtr function on 64 bit systems and see what happens.

Zach Johnson
  • 23,678
  • 6
  • 69
  • 86
  • It was an interesting idea, but unfortunately not. However both of my laptops are running the 64-bit version of windows and they have no problem with this code. – Timothy Strimple Nov 05 '11 at 07:54
  • A went ahead and added the code to use the LongPtr on 64 bit system, and the 64 bit systems still work as expected, however it did not help with the single 32 bit system which seems to be ignoring SetWindowLong. – Timothy Strimple Nov 05 '11 at 08:39
  • Superseded does not mean deprecated. It means that there's a better alternative available - that is all. – Mahmoud Al-Qudsi Nov 06 '11 at 05:43