|
srikanta mohanty wrote: I am getting the following problem while clicking on the download button of my ASP.Net (C#) application
<Tommy Cooper voice>Then don't click it!</Tommy Cooper voice>
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: srikanta mohanty wrote: I am getting the following problem while clicking on the download button of my ASP.Net (C#) application
<Tommy Cooper voice>Then don't click it!</Tommy Cooper voice>
Couldn't agree more. Clicking things is highly overrated and should be avoided when possible.
You can't win.
You can't break even.
You can't quit.
You're welcome.
|
|
|
|
|
Debugging a bitch of a binding problem in MVC and I get the following;
Synchronous XMLHTTPrequest on the main blah blah thread is deprecated because of it's detrimental effects on the end user's experience.
uSoft always looking for ways to make your life easier.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
It has nothing to do with MVC or Microsoft...
Synchronous and asynchronous requests - Web APIs | MDN[^] (It's about Mozilla, but Chrome does the same)...
From my experience it still works, but at you have to stop using synchronous calls...
Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user’s experience. (This is a long process that takes many years.) Developers must not pass false for the async argument when current global object is a Window object. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an InvalidAccessError exception when it occurs.
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Thanks for the feedback, useful info.
Didn't really dive into it much got a crushing headache and nothings been going right.
Well except I did find my binding problem but after 2 hours of hunting it down it was a duh moment. 
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Do you work for CodeProject? That was exactly the same problem that was causing the painfully slow typing[^] last December. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Binding problems remind me of pointer problems back in he day. Solving them could take minutes or hours depending on subtlety and coffee intake.
[update]
Did you ever reply to a message and then realize it was totally out of content? Pre-coffee error
[/update]
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
modified 15-Feb-17 9:47am.
|
|
|
|
|
I've been using SignalR on a couple of projects and I'm very impressed with it. Basically it allows servers to communicate with connected clients in real time or near real time. We're using it on a project to have a collection of instruments notify a server when a process is complete on each instrument. That notification to the server then results in a web app being updated. This allows users to know that status of any instrument from anywhere.
So in working on it I thought of another potential use case for SignalR - record lock/unlock notification:
Consider the scenerio where a data entry form is going to be used by multiple users. You can't just let the user start editing data without knowing if another user is editing that record already. There are many ways to handle locking the UI until no one else is using it, but here's an idea....
The SignalR hub running on the server could maintain a list of views/user id's/states (NotInUse/InUse) and provide real time notification to all other clients when that state changes. Then, the views would update their "Edit" button enabled state in real time when a record becomes available or locked. The server would need functions to release all locks and other stuff, but this is the basic idea. And, it could probably be written generically enough that you could use it right out of the box on any app with little to no modifications.
Without getting into the detail here in the Lounge, do you guys think this is an idea worth of writing up? Any reason you wouldn't use this approach?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: Any reason you wouldn't use this approach?
Yes - I haven't learned SignalR ...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Hence my point that I would make it generic... All you would have to do is include my assembly and subscribe to an event.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: another potential use case for SignalR - record lock/unlock notification:
My previous employer had such a use case (in a WinForms application) and hired some Romanians to make a (Windows) service that did just that.
Anyway, I think it's a good idea.
It's exactly that kind of stuff SignalR is good at, I actually wrote a blog (in Dutch) on it myself (using a simple stock scenario).
You probably can't read the blog, but here's the Git repo[^] in case you're interested.
Good luck! 
|
|
|
|
|
Thanks. I'll take a look.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
It could be interesting. But on the other hand...
Kevin Marois wrote: Any reason you wouldn't use this approach?
I was deeply entrenched in the Microsoft world for well over a decade. Now I have noticed that "the rest of the world" is moving towards Linux and open source. I would assume that there are many alternatives to SignalR. All the script-kids today are talking about NodeJS. Not that I am huge fan of dynamic typing but it is one name that comes up. I think a comparison between different approaches would be fun, but that is only my highly personal and humble opinion. 
BTW there already is a short article here:
What is SignalR and Why Should I Use It?
... such stuff as dreams are made on
|
|
|
|
|
OK, thanks for the article.
My question was do you think a solution for locking that uses SignalR would be a beneficial approach, and is it worth writing an article on?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Ah! I missed that you were into locking specifically. I could be wrong, but my gut feeling is that something more lightweight could do the trick so I tossed out this query:
lightweight signalR - Google
On the other hand, if you already have an ASP.NET server then my point is a non-issue...
... such stuff as dreams are made on
|
|
|
|
|
OK, thanks.. I think SignalR is already pretty lightweight, but that would be a point I'd make in the article
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I did some research for a project and looked/scanned over SignalR but didn't use it.
Would be interested at an article to become better acquainted with it.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Go for it. Sound like good stuff !!! and I want to learn SignalR too
Bryian Tan
|
|
|
|
|
More knowledge is always welcome! I haven't used SignalR before but it sounds like a useful use-case for it. Especially if you succeed in making it a generic like you mentioned! 
|
|
|
|
|
Some thoughts for you to consider (based on having worked on apps that faced these issues in the past):
What would you be sending out a lock message on? When a user starts editing? Bear in mind that you are going to have a distributed environment where it is entirely possible that you would have two users looking to edit the same record about the same time - and due to latency issues, they both start the edit before they receive the lock message. How are you going to handle that?
What about the situation where someone takes out a lock but the application crashes so that they don't release the lock? What strategies are you going to put in place to handle this? There's a similar situation where the user starts an edit and then takes a phone call so that they keep this record in an editing state for a period of time?
What about if you are editing a record that is used as part of a relationship? A lookup table value for instance? Will the consuming applications need to be aware that the record may be changing?
This space for rent
|
|
|
|
|
I think you would use "traditional" locking mechanisms but use signalr only for the notification of waiting clients. So if you hit "Edit" it would say someone is editing that data and you'll then be informed automatically when the resource has become unlocked. Obviously it doesn't solve the issue of unreleased locks etc, but nothing is really going to solve that.
|
|
|
|
|
F-ES Sitecore wrote: So if you hit "Edit" it would say someone is editing that data and you'll then be informed automatically when the resource has become unlocked
There's a latency issue, leading to a potential race condition that's the core of that problem - when two people hit edit at roughly the same time, so you get crossed notifications here. I have seen situations like this many times, so whatever solution the article is going to propose has to be able to cope with situations like that.
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: There's a latency issue, leading to a potential race condition that's the core of that problem - when two people hit edit at roughly the same time, so you get crossed notifications here. I have seen situations like this many times, so whatever solution the article is going to propose has to be able to cope with situations like that.
How would any solution handle this?
One possibility is after a lock is reported back to the client, do another quick check to see if there any duplicates, and use the Date/Time to see who got it first, then quickly re-disable the view of the client that should not have the lock.
Your thoughts?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Pete,
I dusted off this idea I think I'm going to put together a prototype, but I wanted to respond to your points before I do and see what you thought...
Pete O'Hanlon wrote: Some thoughts for you to consider (based on having worked on apps that faced these issues in the past):
I too have done locking mechanisms. They usually involve writing to a locking table. My idea here removes that table from the architecture, but the issues you pointed out still exist. Here's my thoughts...
Pete O'Hanlon wrote: What would you be sending out a lock message on? When a user starts editing?
I would think an Edit button of some sort would be the initiator. The button is disabled until a SignalR message says the record is no longer locked, at which point it becomes enabled. Clicking it performs a lock.
Pete O'Hanlon wrote: What about the situation where someone takes out a lock but the application crashes so that they don't release the lock? What strategies are you going to put in place to handle this? There's a similar situation where the user starts an edit and then takes a phone call so that they keep this record in an editing state for a period of time?
The basics of the hub would have methods to add/remove a lock using the View Name and User Name, and a method to remove all locks for a user. On startup all preexisting locks for a user are removed (in case they previously crashed) and the app would need an administrator function to do the same.
Pete O'Hanlon wrote: What about if you are editing a record that is used as part of a relationship? A lookup table value for instance? Will the consuming applications need to be aware that the record may be changing?
I've always assumed that if a parent view is locked, then so are its child views.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Like.
WebSocket can be a b1tch.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
