Hi Guys,
I am developing a WebApp which relies on Database modifications a lot, and I have a couple of issues, especially when latency is starting to play its part in the game as well… What I am intending to do now is: I have a Web Dialog that consists of several buttons, TextFields, and a Progresswheel. As soon as someone clicks the “Add” Button I would like the progress wheel to show, do the database modification - and once its done show the button again. The fun part is, that if I am doing it with the code below and a breakpoint set, whenever the breakpoint triggers, the buttons are still being shown and the progresswheel is not.
Heres a snippet…:
[code]
// Show ProgressWheel and Hide Buttons
progwheel.Visible=True
cmdAdd.Visible=False
cmdClose.Visible=false
cmdDelete.Visible=False
cmdUpdate.Visible=False
if lstFixtureType.RowCount = 0 then
dbAddFixtureType(txtFixtureType.Text,txtDMXChannelCount.Text, txtFixtureCategory.Text) // The Breakpoint is set here
else //… [/code]
What am I missing?
Could you have the add button do your progresswheel and buttons go away and run a thread to do your database updating and have a timer check the progress on the thread?
thats what I thought about as well - and it would probably work, but then I’d probably end up having approx 120 threads and timers cluttered all over my project :-/
I was just hoping for an easier alternative 
Not sure how you have it set up but maybe you can have 1 progress wheel and have the timer either turn it on or off checking the button code to see if it’s finished.
Yes, I currently have one progress wheel per dialog; I guess I am going to move the timer to the parent webpage, create a new modal dialog which will be shown, as soon as the button is pressed - and will be closed as soon as the thread finishes.
Just implemented that, and for the way I have the app laid out it is a huge pain in the ass with threads just to work around the code not happening when it should. It actually works in a Desktop app :-/
So here’s the thing. When your code is executed on the server, no response is sent to the browser until ALL of the code which is triggered by that event has been run. So in your example, the JavaScript commands to show the progress wheel gets queued, the database ops are done and then the cmd to hide the progress wheel is queued. Once the event handler exits, all of the code that was accumulated is pushed out to the browser.
So as you found, having your database code run in a thread is definitely the right way to accomplish this on the web. I’d also argue that if the database code takes a long time on the desktop, a thread might be the right solution there too, if just to keep the ui responsive.
Hmm I see, theres probably have no way around threads. I assume ALL of the code also means nothing is sent to the browser until all of the methods I call from within this particular event are executed.
On another note, what is the best place to put my threads, as it appears (by the language reference) I can not have them within my webDialog, not even subclassed?
I don’t know about the thread in the dialog… should be really fast if you’re just adding one record.
But what about this…can you add code to the button giving you a progresswheel.visible=true and … turn on the timer passing… since the event is complete in the button code the wheel will spin and the timer will run once executing the DB code and then at the end turn off your wheel.
Actually, that could work - I am not worried about blocking the user interface - In fact, I might even add another WebDialog which is blocking the UI for the time it takes to do whatever the application needs to do.