|
Hello!
What is the code to force Windows to refresh the display settings? I have a VB .NET Forms application that has been steadily updated long enough that it has moved through multiple .NET versions and deployed across Windows XP, Windows 7, and now Windows 10 (we were able to avoid Vista and 8).
Now, on Windows 10 running on an HP, I have a display problem. The problem in the HP, but there is a work around that I would like to trigger from the application.
To fix the problem, after launching the app (from DEV or EXE):
1) Dock / Undock (switching between native and attached displays)
2) Open display settings and change something (resolution, scale, etc.)
3) Perform some other, similar display adjustment that requires the OS to update all of the resolution/scaling constants.
In each case, when change the display or display settings, the problem is resolved, and when I change back, things continue to work fine. It also does not matter if I start on the laptop display or the attached displays. I can duplicate the behavior and fix on multiple HPs running windows 10.
What I need is code to force Windows to refresh the display settings.
Background: The problem is clearly in the OS, likely the display driver. However, HP has been having issues with display drivers ever since the rush to market with the Thunderbolt and they have yet to fix most of those problems. HP blames Microsoft, Microsoft blames HP, nothing gets fixed.
Using app level functions, such as Refresh, and PerformAutoScale do not do the trick. The problem appears to be that windows is reporting different values to the application on container size, and usable size. The app initially draws the controls to the correct container size, but then only repaints a smaller usable size.
Making the window smaller (reducing the container size to below the apparent usable size) and then bigger again, does not make the problem go away - there is a fixed "usable size" that the app will not repaint beyond the borders of, even when the container goes beyond that size. What is interesting about this is that the app will update the data in the controls beyond this "usable size" - it just doesn't properly repaint, instead it adds the new text on top of the old text. It also leaves behind the drawn window edges as the container is sized larger.
Another interesting tidbit is that I can run the app, perform the work around to "fix" the problem, and then close the app. Upon reopening the app, the problem returns, and the work around is again required.
Please help with both a code driven work around, or even better, an OS level fix.
The particulars:
1) VB .NET in Visual Studio 2017 (version 15.9.16)
2) Windows 10 (up to date per Microsoft)
3) HP ZBook Mobile Workstation "Bang & Olufsen" with i7, lots of memory (has no problem with Solid Works 2017)
4) Display drivers for both laptop internal, and Thunderbolt dock external up to date
5) Behavior duplicated on second HP (same config) with Windows 10; same app continues to run just peachy on second HO (same config) running Windows 7.
Todd
|
|
|
|
|
Windows 10 does not "default" the same as previous versions.
In some cases, it will set a "minimum" height or width which any attempt to override, without changing the "minimum", will be defeated.
In other case, a property that was expected to return a number in ALL cases, will now return a NAN except in certain cases, and another property should be used (e.g. "actual" size versus simply some other dimension).
I suggest you "prototype" some "new" forms under Windows 10 and get familiar with the "live property" inspector before concluding it's hardware, drivers, etc.
And upgrade to VS 2019, insuring you understand what it means to select a particular "Windows 10 Build" version.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Not sure I follow most of your thread, but tried your advice of prototyping new forms. Found the behavior extremely inconsistent, but eventually repeated.
Disregard all of my "theory" on what it is doing and focus on the symptoms:
1) When the Form is larger than a certain size (the X and Y dims of this "max size" are not consistent), the controls, specifically a DataGridView in a TableLayoutPanel do not properly repaint as the content, size or position is changed.
2) Changing the values of Minimum Size, Maximum size, Starting size, Starting position, Window State, etc. do not have an effect (other than, of course, restricting the size to small).
3) Altering the OS level display adapter settings (such as Zoom) after running the app makes the problem go away for that session.
4) This only happens on Windows 10 with the HP Z Book. Of note: the HDPI, Zoom, and DPI-Awareness crap all came at the same time with Windows 10 (even though the underlying hardware is literally the same).
On the last point, VS gives me 2 options (starting with or without automatic scaling), neither of which works.
Disable DPI-awareness in Visual Studio - Visual Studio | Microsoft Docs[^]
Thus my original request of how to programatically adjust the display zoom.
|
|
|
|
|
|
You are focussing heavily on code, and how to solve this "problem" in the Windows UI.
You stated yourself that it only happens on a particular model. No amount of code is going to help with a faulty driver.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Maybe a dumb reply by me, but did you set your anchor points?
Like a control on the top left of a form anchors to the top left.
I don't like talking about this subject because it's sort of voodoo here, but I'm pretty sure with VB Winforms, when a form changes size, or a label changes text, it sends a message to the Windows OS message pump just like in Win32, and the message pump queues the screen change or update. I was told to never use "Application.DoEvents()" because it very bad but I suspect it's purpose is to pause your program execution and let the message pump catch up and process it's queue so that the screen can update.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
I'm using DataGridViews docked "full" inside a TableLayoutPanel. Therefore, I haven't touched the the anchor points.
Changing OS level display settings (such as Zoom) makes the problem "go away" for the current session. So, I'd like to be able to change the display zoom programatically until HP and Microsoft come to a solution.
|
|
|
|
|
Todd (10789346) wrote: until HP and Microsoft come to a solution
Don't count on that ever happening.
|
|
|
|
|
I appear to have found a solution, and it does not require invoking OS level setting changes.
Through a lot of trial and experimenting, I found the behavior is specifically related to the DataGridView control. Through some research, an old thread proved to have a workable answer: Invoking DoubleBuffered on the control.
The details are on StackOverFlow: [^]
The code is here:
typeof(DataGridView).InvokeMember(
"DoubleBuffered",
BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.SetProperty,
null,
myDataGridViewObject,
new object[] { true });OR
DataGridView1.GetType.InvokeMember("DoubleBuffered", Reflection.BindingFlags.NonPublic Or Reflection.BindingFlags.Instance Or System.Reflection.BindingFlags.SetProperty, Nothing, DataGridView1, New Object() {True})
|
|
|
|
|
Hi , Developers
listBox created in window class #32770 as OWNERDRAW when i want to retrieve itemdata , give me some strange character examle i use addstring and character : "D"
Case WM_DRAWITEM
pdis as DRAWITEMSTRUCT
Select Case pdis.itemaction
case oda_select
txtcount=SendMessageA(pdis.hwnditem,LB_GETTEXTLEN,pdis.itemdata,0)
buff$=space$(txtcount+10)
SendMessageA pdis.hwnditem,LB_GETTEXT,pdis.itemid,buff$
debug.print buff$
end select
if no use listbox ( Style : Drawitem ) it gives me right character as i see in listbox but when use drawitem to draw my listbox charaters change and only one item of it showed me
modified 8-Oct-19 13:13pm.
|
|
|
|
|
VB uses Unicode for strings so you should use SendMessageW not SendMessageA.
|
|
|
|
|
hi
SendMessageW (For All even get lenght ?) i use now but when itemCode change ( ODA_SELECTED ) buff$ no clear
,possible to put a right code if you are tested before ?
|
|
|
|
|
Sorry, I don't understand what you mean by "buff$ no clear". Using SendMessageW ensures that any text strings returned will be in Unicode format.
|
|
|
|
|
means set buff$ empty , am i wrong ? in EM_SETCUEBANNER Also shows unicode(not related to this post but maybe you know the way to solve it )
after each selection no need empty the buff$?
|
|
|
|
|
The result of LB_GETTEXTLEN is :
Quote: The return value is the length of the string, in TCHARs, excluding the terminating null character.
So you need to allocate a buffer at least this length plus 1. The LB_GETTEXT message will fill the buffer with the text of the control, followed by a NULL character (hence the +1 in the previous part).
The EM_SETCUEBANNER message also needs to be sent with SendMessageW. In fact you should use the W suffix on all Win32 calls, as all your text will be Unicode. Unless, of course, you add some text manipulation to make it ASCII.
|
|
|
|
|
Hi
Tooltip Created ( Created No Problem here ) And Used TTM_ADDTOOL ,
To force Display The Tooltip Needs Sending TTM_POPUP Message But , Never Show when mouse over the control ( WM_SETCUTSOR )
|
|
|
|
|
Assuming I have truyen.exe file, I want to give notice to truyen.exe file to output the message with the syntax: Drive:\truyen.exe "example communication", I want to pass the file to truyen.exe. how to declare exe yourself ?
|
|
|
|
|
Hmmm your message suffered badly in translation and you question is very unclear.
Fact: VB6 is no longer supported and has not be for more than a decade. Most of us have moved on from that language.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
hi
i Subclass a Window ( other app ) and Create Button inside it but not receive any message even wm_command , when use tab not get focus
|
|
|
|
|
Your quesiton isn't answerable as is. All of the important information is missing.
Show the code you used to create this window and button. And what do you mean by "other app"?
|
|
|
|
|
Subclass The InputBox ( Not Create Window ) And Create Button
hwndBtn=CreateWindowEx(0,"Button","",WS_CHILD Or WS_VISIBLE,300,60,49,26,hwnd,IDC_BTN3,0,0)
So Created In Window But Not Recieve Any Message Example Not Get Focus
i used follwing document also
WS_TABSTOP0x00010000L : The window is a control that can receive the keyboard focus when the user presses the TAB key.
InputBox Have 2 Buttons , 1 Static And 1 Edit Control
i Created another button inside it behind the button(cancel)
My Friends I ve created button !!!!
see third case
Select Case WM_COMMAND
Case 1 ' IDOK
SetWindowTexta hwnd,"ok"
Case 2 ' IDCANCEL
SetWindowTexta hwnd,"Cancel"
Case IDC_BTN3 ' <--- Does Not Work
SetWindowTexta hwnd,"New BTN"
End Select
***Note :
when hook and subclass the inputbox I did not recieve WM_INITDIALOG so that i can Put the createButton Code finally put the code in WM_SHOWWINDOW to create it
modified 6-Oct-19 12:08pm.
|
|
|
|
|
A single line of code does not explain anything at all. There are many places where you could put that and it would not work. Please edit your original question and add some proper details.
|
|
|
|
|
This is clear , the Button not recieve any message from its parent and my question and problem clearly specified maybe somebody did it and can help me
|
|
|
|
|
No, your problem is not clearly specified, and we have no idea where that CreateWindowEx call is going, or how the parent is sending messages to it.
|
|
|
|
|
As per your comment if button or any control create with CreateWindowEx function through Hooking-Subclasong , that button never get focus and needs Buttonproc ?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
