Yes, sites that are picky about which special characters are acceptable is one of my pet peeves - and there is no excuse for this if the code behind the text box is properly written!

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

I am not sure what you mean by 'chroma key' in this context. The placeholder 'color' I am using for the transparent area is a very dark gray - the entire palette of the image is grayscale. If you blend black, white, and a pure grey in any proportions, you shouldn't get bright green!

Since the clock face is invariant, it seemed to me to make sense to use a static image. My other experiments, described in the other 'branch' of this thread, would also suggest that your approach would not solve the haloing problem with transparency.

Well, that was very interesting! Doing as you suggested does not solve the problem. If you use a sensible sized pen (fairly small), nothing visible happens, and the 'halo' looks just as before, though there is a suggestion of it disappearing at the points where the drawn circle overlaps the edges of the original image (the top, bottom, and two sides). If you use a thicker pen, it is more obvious that the 'halo' is gone at the overlapped edges, but it is just pushed out to the edge of the drawn circle over the rest of the rendered image - it still always appears where a 'transparent' pixel was adjacent to one of another color, whether that pixel was part of the original bitmap or subsequently drawn on the Graphic. Presumably, therefore, it is an artefact of the [Bitmap].MakeTransparent() Function, but I have no idea why it has not (as far as I can tell) been described before Parenthetically, I now see that that function forces the Bitmap on which it is invoked to 32bppRgb mode, since that format has the alpha channel which it needs, so any attempt to use a different format would be pointless.

Since writing my last message, I 'un-antialiased' the source image and tried again. Even though there are only three colors of pixels in the new source image (pure black, pure white, and the very dark gray used for the area to be rendered as transparent), the panel appears exactly the same when displayed on the desktop - with the thin green 'halo' round the clock. The new source image can be found here. It really does look as if the false color aliasing is happening when the image is created/initialized.

Yes. I was reusing old code which allowed color images. I wasn't the original author, so I didn't change anything that I didn't think absolutely had to be changed, and I wasn't sure whether any of the other reused code implicitly assumed the specified format. Indeed, experimentation since you raised the issue showed that using other formats (including indexed and grayscale ones) does cause other problems.

Yes. Looking at the image at a very high zoom, I do now see that it is antialiased. However, the 'smoothing' is all grayscale, which would not be a problem if it carried over to the final displayed image. It is the green false color introduced by the Panel's rendering of it that is the major issue. I will see if I can 'un-antialias' the original image, but that may introduce different, but equally unsightly, problems.

Thanks for your response, which makes sense. I have, however, now tried setting the SmoothingMode to None in the Panel's overridden OnPaint Event without changing the (mis)behavior. I assume that the aliasing is occurring earlier, probably when the image (a .png file included and passed as a Resource item) is read in and converted to its internal Bitmap format, and I don't see how I can influence that step.

I have a small clock/calendar Applet that lives on my desktop, since (for at least some purposes) I like to have an analog clock. I recently decided to clean up the Panel that displays the clock to make the square background to the round clockface transparent, so that the clock face would just 'float' over the desktop. I discovered that this was not simply a matter of making the relevant area in the source image transparent, since the transparency 'disappears' when the image is loaded into the Panel. However, the following load code almost works when the panel is displayed:

Private Function ConvertImageToRGBFormat(img As Image) As Image
        Dim temp As New Bitmap(img.Width, img.Height, System.Drawing.Imaging.PixelFormat.Format32bppRgb)
        Dim g As Graphics = Graphics.FromImage(temp)
        g.DrawImage(img, New Rectangle(0, 0, img.Width, img.Height), 0, 0, img.Width, img.Height, GraphicsUnit.Pixel)
        g.Dispose()
        temp.MakeTransparent(temp.GetPixel(1, 1)) ' pixel(1,1) is part of the transparent area
        Return temp
End Function

I say that it 'almost' works because the square background of the displayed image is, indeed, transparent, except for a very thin green 'halo' round the clock. I typically use bright green as the guide color for image areas that I am going to make transparent, so I initially thought that the feathering at the edges of the clock had caused this, and changed the color for the transparent area to a dark gray (similar to the background color on my desktop), so that there was no green anywhere in the image (or in its color palette). Notwithstanding this change, the green halo persists. This is how the Panel appears on the desktop, and this is the source image. Does anyone have any idea what is going on?

BryanFazekas wrote:

This is what I do. If I don't understand the code, I have no idea how I'd translate it.

If you don't understand a block of code at all, you can't translate it, but translating a code section that you think you understand into another language can be a very good test of whether you really do, since it forces you to concentrate on details of the implementation that you might otherwise skip over.

According to what I have read, Hyper-V emulates TPM for VMs running under it. Your experience strongly suggests that it can do this even if the host doesn't have the hardware and/or doesn't have it enabled.

In most of the first world, the recommendation is that people who (know that they) have had COVID should still be vaccinated, because there is some evidence that the vaccine gives additional protection (particularly) against strains of the virus other than that which the individual was infected. While a local reaction (soreness, aching), particularly to the first dose of the vaccine, is more common and may be more severe in someone who has previously had the disease, there is no evidence that more severe vaccine reactions (which are very rare, in any event) are more frequent in such individuals. Consequently, concern that you may previously have had a very mild infection should not prevent you from accepting vaccination. If you have more specific concerns, you should discuss them with a trusted physician. I write this as a physician and volunteer COVID vaccinator.

I removed McAfee from my main computer and switched back to Windows Defender, when McAfee kept flagging the executable of an application I was developing as 'suspicious', and wouldn't let me run it until I identified the executable as 'safe' every time I updated it.

One of the problems with today's business environment is the emphasis on pieces of paper rather than demonstrated skills and knowledge. However, I wouldn't want to be treated by a physician who didn't have a Medical degree and a license! For the lay person, the pieces of paper provide at least some assurance that the person holding him/herself out as an expert really is.

I have a (WiFi connected) Roku, and have been very happy with it. The only significant problem I have had has been with trying to use it as a remote Miracast (q.v.) target for 'projection' from a Windows 10 laptop. Although this is supposed to be feasible, I have never been able to get the two connected in a way that works. My workaround has been to connect my laptop directly to the TV by an HDMI cable, but this would not help someone who wanted to make a Miracast connection from a device that was located further away from the TV. One other warning: There is currently a squabble going on between the Charter/Spectrum people and the Roku people. If your Roku doesn't come with the Spectrum App (mine didn't), you will not be able to download/install it until the two parties come to an agreement, which may be a while.

Largely for historical reasons, I run a (VPOP-3) mail server on my home network, which downloads all the email from the various outside mailboxes my wife and I use using POP3 and puts it in one local mailbox for each of us. The other evening, my wife was getting a new credit card, and was (repeatedly) not receiving a message sent by the bank with an attachment that she needed to 'sign'. We ruled out it being spam-trapped locally, and it eventually occurred to me to login to webmail for the MidPhase-hosted mailbox to which it was being sent and check there. It turned out that the message had been spam-trapped there by a system that must have been introduced without warning (relatively) recently. It also turned out that there were a lot of other messages in both of our accounts there that had been incorrectly spam-trapped - mostly mailing list and advertising type ones which my system would have trapped, but also some receipts and shipping notices. It was not obvious how to turn off spam trapping in the mailbox's Settings, so I contacted MidPhase Support, only to be told that it could not be disabled. I think that I have found a workaround (though the tech said that he didn't think that it would work), but I am posting to warn others whose email may be hosted by MidPhase about this problem. If you use their webmail, you just have to check the spam folder, and the same is presumably true if your client uses IMAP, but if you get your mail via POP3, be warned!

On global variables in Python: it is misleading to say, without qualification: "If you define a variable in a file it is global to every function in that file." It is true that if you define and/or use a variable outside a function, it becomes globally visible to 'subsequent' code within the file. It is, however, treated as read-only outside its original scope unless it is specifically declared as global within a function definition. I can see that even the read-only visibility of such variables may be offensive to those to whom the thought of global variables is anathema, but I do not find it so.

In fact, if you want to hike and photograph a trail or other 'sight' so that it can be included in Google Street View, Google will lend you a camera pack. You need to be a very serious hiker, though. Last time I checked, a couple of years ago, the pack weighed something like 40 pounds (18 kg, for those who don't think in pounds).

I have used APC UPSes for many years, on both sides of the Atlantic. Other than needing batteries replaced, I have only had two fail on me - one after almost 11 years of continuous use (it stopped charging the battery), and one after a couple of weeks' use (persistent error indication). I called APC's support up about the latter and, after I described the symptoms, they shipped me a new one out overnight express, with a prepaid shipping label to return the defective one in the same packaging. I did once buy a 'store-brand' UPS, and it died within 18 months. I have no experience with CyberPower. I have also certainly never seen a UPS fail in the exciting way described by the reviewers you quote.