I don't undersatand your definition of client and server. In web terms, a client is traditionally thought of as the end-user (or their browser), and a server is what sends them pages/data/whatever upon request. A server can only know if a client is still connected if it receives something from the client. So a so-called "push notification" (from ther server to client) can only happen if the server has had such a "something" establishing (or keeping alive) a connection - that "something" telling it where to push the notification to. SO how does this differ from the client using a simple AJAX call on a setTimeout to ask the server if it has anything new it wants to say? As far as I can make out, the only difference is that it can run as some kind of background service - well, whooppee, I can do without that. Seems a whole lot of effort for little benefit, though I guess someone likes it. It certiany seems to be popular (amongst web devs anyway; not so sure about end users.)

OK... but isn't that more or less what Wombat is saying? The only one that can open a connection is the user's browser - they are the client - and the server can only "push" a notification to them once they (the client) have opened a conection. What's puzzling Muppet then is, if this is the case, how it is called a "push" - it's just a case of the client polling the server until the server says "OK, now I have new message for you" and returning it - that's not really any different from a client pull, and can be done with a standard JavaScript setInteraval function and AJAX call... (and when a user subscribes, set a persistent cookie that tells the page to initiates this every time it is opened).

Muppet has asked Wombat something about web push notifications - a topic they both know next to nothing about. Q: who knows even less than who? Wombat you cannot push something to a 'normal' user .. their modem/router firewall will block it. So it is a sort of fiddle... one way or another you have to get the user to install some sort of program. I gather browsers are maybe going to add some sort of such facility... Muppet This is precisely what you can do now... look up "Web push notifications" - it's all the rage. You have to get permission from the user (browser), but that's all. Wombat well if the browser has now got that option... yes... it looks like a push to the user... but actually the pushed messages are stored 'somewhere' and your browser pulls them Muppet No... there is a push... Wombat yes from your end you just push ... but the browser has to actively retrieve them you cannot push a message into a user's PC .. well not unless they set their firewall to always accept unexpected messages Muppet Your browser is not constantly polling the server in case there's a message for it... the server tells (pushes to) your browser it has a message for it Wombat no it cannot! it simply won't get past the router .. unless something is telling the router it wants it the messages will just sit there waiting if the user's browser is offline Muppet of course it can get past the router - all routers are open to web traffic Wombat because your browser has sent out a message .. and the router will accept a response from whoever the message went to.. within a time limit Muppet and these ntofiicatsion work by your broswer telling the server it will accept pushes from it - this is why you have to subscribe to them Wombat yes.. but the brower still has to ask for them! .. if you just fire a message at a router... how does it know which of many computers using it should get that message Muppet it knows by which browsers are signed up to accept them Wombat no.. the router has no idea what program is using it Muppet so how does the browser know when to ask for a message then? Wombat becasue when you tell it to allow notifications - from a specific source ... it remembers that and asks occasionally.. i think the default timeout for the router is about 15 seconds. Muppet no - I am 100% sure that isn't how it works Wombat it will be interesting to time how promptly the notification appears Muppet anyone can simply poll a server on a timer

Silly me - I meant WebForms, of course, not WinForms... My (admittedly limited) understanding of this class, is that it allows you to override the default HTML rendering code for an ASP.NET web control. It shouldn't, AFAIU, affect any of the properties ro events otherwise asociated with the control - only the HTML markup .NET uses to render it on teh page. OK - so I've tried this for a the radio button adn checkbox controls. It all seems to work, and the controls render with the markup I want. If I set the AutoPostBack property, the HTML includes the usual

onclick="javascript:setTimeout('__doPostBack('[ctrl ID here]','')', 0)"

that we all know and love in such controls... and indeed, the controls will post the page back when clicked/changed, and the "correct" changed state of is shown on the posted back page. BUT... the control's CheckedChanged server-side event is not being fired. Am I operating unders ome basic misunderstanding of this class?