That's what I thought you meant, hence my comment that blending white, black, and gray shouldn't give you green!

Acceptable. 20% good leaves 80%, of which 20% (=16%) must be OK, leaving 64% shite. Similarly, 20% of the good 20% (=4%) is excellent. :laugh: Robust Services Core | Software Techniques for Lemmings | Articles The fox knows many things, but the hedgehog knows one big thing.

:laugh:

I used to use ESET, but then changed to Cylance and love it. No virus libraries which are by definition out of date, just intelligent monitoring of what comes in.

It happens to me embarrassingly too often. :-O

After spending a lot of time researching this, I was able to come up with a solution which works, but there should be an easier way! There are a lot of 'gotchas', apparently 'baked in' to the design of the control. Not only does the view scroll up (by default) when you arrow down into a cell in the last row, but it also scrolls up if you arrow left or right while in the last row. Implementing my solution involves a number of steps: 1) Subclass the DataGridView control so that you can (optionally) override its ProcessCmdKey method to disable special handling of the arrow keys (you don't actually need to mess with the up arrow key, but I found it easier to disable all of them. 2) Substitute references to your new MyDataGridView control for those to the original version in the containing Form's Designer.vb file - for me, using VS 2013, two references needed to be changed for each affected control. Then, either in the designer or in initialization code, set the option to disable the arrow keys for the modified controls. 3) Write code for the KeyUp and KeyDown Events for each affected control - the KeyDown code does apparently need to be there, but it only has to set the Handled event argument to True; the KeyUp code has to do the work of changing the current cell appropriately for the arrow key pressed. For any arrow keystroke that results in a move to a cell in the bottom row (including a lateral one), the KeyUp code also has to set the control's FirstDisplayedScrollingRowIndex Property to 0 after implementing the move. This is what scrolls the view back down again to abolish the empty row, but it does cause a visible 'glitch'. 4) If you don't want the view to appear to 'glitch' when the user is moving to or on the bottom row, it is best to surround the working KeyUp code with calls to disable and re-enable screen painting while it is (in effect) moving the focus about.

The problem seems to be what I can only describe as a deficiency in the Visual Studio environment - the clue was the information message described in my previous response. My usual way of testing an isolated Sub or Function while I am developing an application is either to invoke it directly from the Immediate Window, or, if this is not convenient (as it frequently isn't), to write a stub Sub which uses it and invoke that from the Immediate Window. This has always worked for me before. It appears that there is an issue with doing this to test (at least some) WebClient code, presumably because of some aspect of how code invoked from the Immediate Window is interpreted and run. If I put the code clipping from my first message in the Form_Load Function of a Windows Forms App and run the App, the code runs normally and returns the expected JSON string. If I put the identical code in a Public Sub and invoke the Sub from the VS Immediate Window, it throws the ThreadAbortException that I originally described. Perhaps the most bizarre aspect of this is the fact that the misbehavior is dependent on the URL in the request being an HTTPS one - as I noted, requests involving HTTP URLs are handled correctly, even when the code is run from the Immediate Window.

As per the other discussion looks like Windows has made a structural change which is perfectly normal. You should be able to go around the problem by just using Windows API. The other guy with the problem said he was losing the last word but I am pretty sure that is because he didn't have enough room in the box for the wording because the font was obviously slightly different spacing. I told him about using the negative height which forces absolute height selection of font and gives windows no latitude to play with it. I don't know what parameters the original MFC code used in selecting a suitable font but you just need to work it out. WM_SETFONT should and must work because it is an API message if it doesn't work correctly it would be given a high priority to fix from Microsoft because it could effect any and every program. This should not be a big issue to fix. Using frameworks makes things easier the penalty is sometimes things can change in the Windows API that break the frameworks. The alternatively would be Microsoft not ever be allowed to change anything which as one of your comments already says this stuff has changed multiple times over the years already. In vino veritas

Well, I have a workaround - if I delete the reference to the Primary Key field in the DataTableAdapter definition, the code works and the database does get updated properly when I .Update it from the table. Since I don't need access to the Primary Key in the VB.Net code for anything, this is acceptable, but I still don't understand why the older code, whose table definitions include the relevant Primary Keys, works.

I had not previously tried that, but I did, with Debug.Print commands inserted to display the information. Unfortunately, the crash is a Windows "This application has stopped working" one, which is apparently not prevented by exception-trapping the line of code that provokes it, and it won't let me 'Debug' it with the open instance of VS.

harold aptroot wrote: if you have an array of Rectangles you can still call Inflate on them Yeah, Rectangle is a mutable struct! I assume they didn't make it immutable for some backward compatibility reason. I had never considered the implications of this (apart from the normal) until seeing your previous post - interesting :thumbsup: Dave Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum. Astonish us. Be exceptional. (Pete O'Hanlon) BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)

5. In this case, all the messages are not the same size (the message header length is constant, but a message can contain 0, 1, 2, or an arbitrary (2 < n <= 26) number of additional bytes of data). Also, for a number of reasons related to the device and application, I want to be able to identify and (if necessary) modify a pending command, if another command of the same "class" is issued before the first one is executed, which may be up to 10 seconds later. The thermostat is relatively slow (in computer terms), and can only do one thing at a time, but I don't think that this can be causing the need for the delays. If I don't put them in, some of the UPD packets are never sent. It is as if the outgoing UDP port needs time to "clear" before it will send a new message.