show_loading bar whenever I want

Scheduler Javascript
#1

Hi there,

    On the scheduler, when one of my users creates a task, it automatically sends an email to whoever's concerned. However the call to the php "mail" function inevitable causes a small "freezing" of the scheduler (something between one and two seconds at most). This is nothing really critical, but I'd like my users to know something's actually happening during those few seconds so that they don't think the application's frozen up or something. Now I've stumbled upon:

scheduler.config.show_loading;

Which shows a loading bar, which in turn would be absolutely perfect for what I have in mind. However, it only appears when I call scheduler.load (which makes sense since this is a loading bar). However, I would like to know if there was a way to toggle it on and off whenever I want, not just by calling scheduler.load?

Thanks in advance.

Osu

#2

You can try to use

scheduler.callEvent(“onXLS”,[]);
and
scheduler.callEvent(“onXLE”,[]);

to show|hide loading progress
As far as I can see , it will not cause any unwanted side effects.

#3

Hi Stanislav,

     For some reason, the

scheduler.callEvent(“onXLS”,[]);
scheduler.callEvent(“onXLE”,[]);

Produced no results whatsoever. Granted there was no error generated, but I might as well have put a blank line. Anyway, thanks to a bit of snooping in the scheduler_debug.js, I was able to learn how you made the loading bar appear and replicate more or less the same thing. However, I figure I’d share some of the pain I had to endure thanks to IE and Chrome’s stupid behavior.

First of all, I put the code in the onEventIdChange() event since, in my case, that’s exactly where the loading bar should appear. So I copied your CSS rule and added it to my main page:

<style>
.my_overlay {
width:100%;
height:100%;
position:absolute;
z-index:10000;
top:0;
left:0;
background-color:black;
opacity:.1;
filter:alpha(opacity=10);
</style>

In retrospect, that probably wasn’t necessary since your CSS page is already included in my main page, but for clarity purposes, I figured it was a bit easier for me to have it there than to go in the scheduler’s CSS and find again. After that, it was really simple, I created a function that added the necessary elements to the document’s body and called it within the onEventIdChange() and, once the treatment was done, I simply removed the elements as so:

function putOverlay()
	{
		var overlay = document.createElement("DIV");
		var progressImage = document.createElement("img");
		//overlay.className = "my_overlay";
		overlay.className = "my_overlay";
		overlay.id = "overlay";
		progressImage.id = "progress";
		//progressImage.src = "img/progress.gif";
		progressImage.src = "img/loadingtest.gif";
		progressImage.style.position = "absolute";
		progressImage.style.left = (screen.width / 2 - 192) + "px";
		progressImage.style.top = (screen.height / 2) + "px";
		progressImage.style.zIndex = "10001";
		
		//overlay.id = "overlay";
		
		document.body.appendChild(overlay);
		document.body.appendChild(progressImage);
		//alert("DFFDSFSDF");
	}

scheduler.attachEvent("onEventIdChange", function(old_event_id,new_event_id)
{
if (firstRec || (!firstRec && eventCopy.RecId == "NULL"))
		{
			var xmlhttp;
			putOverlay(); //adding the overlay and the loading bar to the document's body
			
			if (window.XMLHttpRequest)
				xmlhttp=new XMLHttpRequest();
			else
				xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
					
			xmlhttp.open("GET","include/emailInsert.php",false);
			xmlhttp.send();
//Removing the elements now that the treatment's done
			document.body.removeChild(html("progress"));
			document.body.removeChild(html("overlay"));
		}
}

So, all nice and dandy, right? WRONG! Firefox had absolutely no problems with this approach, but both Chrome and IE completely and absolutely refused to display the elements I added… unless I added something like an “alert” box to sort of freeze the code temporarily. I did not figure out why exactly these browsers behaved that way, but I did find a decent workaround.

I simply put the call to the “putOverlay()” function in the “dp.onBeforeUpdate()” event and things started to work relatively correctly.

dp.attachEvent("onBeforeUpdate",function(id,status){
			var ev =  scheduler.getEvent(id);
			
			if (status == "inserted" && (firstRec || (!firstRec && ev['RecId'] == "NULL")))
				putOverlay();
				
			return true;
		});

So, now the elements do appear in IE and Chrome, but for some reason the animated gif freezes on its second frame of animation. Again Firefox has absolutely no problems with that code so go figure. It’s not exactly perfect, but that’s good enough for me.

So there you have it. I hope my experience can benefit someone out there… and if you know why on earth the animated gif freezes up, you’re welcome to tell, but it’s really not critical at this point, it’s just me being curious.

Thanks again for your answer Stanislav :slight_smile:,

Osu

P.S. In case you’re wondering, the condition I put in the onBeforeUpdate is simply to make sure I don’t add multiple overlays when I insert recurring events. I’ve tested it and it works, just in case you might be thinking the problem comes from there.

#4

xmlhttp.open(“GET”,“include/emailInsert.php”,false);
This is a sync ajax request, right?
During sync request browser pause all inner processes. Including gif image showing|animation.

You can change whole code as

showOverlay(); //dhtmlxAjax already included in dhtmlxscheduler.js dhtmlxAjax.get("include/emailInsert.php", function(){ hideOverlay(); });

In such case async. ajax request will be called, which doesn’t block animation or other updates in browser.

#5

Now that’s what I call an answer :smiley:. In three lines, you’ve solved the mystery that puzzled me for almost an entire day. I tried your suggestion and it worked like a charm :slight_smile:.

Thanks a lot :slight_smile:.

Osu

#6

Another question related to this topic:

When I delete a series of recurring events, I’m doing some work server-side that deletes the events in the database. Works like a charm, but the scheduler’s yellow strips remain and become dangling. To cope with that, I’m adding an attribute that’s basically a list of all the events deleted server-side and, client-side, I loop through it and call the scheduler.deleteEvent() to get rid of them like so:


dp.attachEvent("onAfterUpdate", function(sid, action, tid, tag)
		{
			var xmlhttp;
				
			if (window.XMLHttpRequest)
				xmlhttp=new XMLHttpRequest();
			else
				xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
			
			//if (action == "inserted")
			//{
				//xmlhttp.open("GET","include/emailInsert.php",true);
				//xmlhttp.send();
			//}
			if (action == "updated")
			{
				xmlhttp.open("GET","include/emailUpdate.php",true);
				xmlhttp.send();
			}
			else if (action == "deleted")
			{
				xmlhttp.open("GET","include/emailDelete.php",true);
				xmlhttp.send();
			}
			
			if (tag.getAttribute("deletedEvents") != null)
			{
				var info = tag.getAttribute("deletedEvents").split(";");
				//scheduler.clearAll();
				for (var i = 0; i < info.length; i++)
				{
					//l'événement sur lequel on se trouve est déjà effacé
					//donc, pas besoin d'appeler deleteEvent
					if (info[i] != tid) 
						scheduler.deleteEvent(info[i]);
				}
			}
			
			scheduler.load("calendrierConnecteur.php");
			return true;
     	});

This works perfectly and the events are indeed removed from sight… after a bit. Now, the first event I’m on when I choose my “Delete all” option disappears virtually instantly. For the rest of the events, the text immediately becomes crossed over to tell the event is in “deleted” status… and then there’s a delay of about 1.5 to 2 seconds before they indeed finally disappears.

I don’t particularly mind the delay, but I thought I’d also put a loading bar to it so that users can’t do anything while the state is “inconsistent” so to speak. Now, it’s easy to know where to put the “showOverlay()”, but where do I put the “removeOverlay()” in this case?

Also, and the problems might be linked together, when I delete a series of events, only one email’s being sent. Mind you that’s exactly what I want, but it still feels strange that the scheduler.deleteEvent() doesn’t eventually trigger the onAfterUpdate() like it does when I click on the “Delete all” button of my lightbox.

Anyway, that’s a minor problem per say, but if you could give me a small pointer I’d be grateful :slight_smile:.

Thanks in advance,

Osu

#7

Hello,

If I got that right then you have deleted all necessary events on the server side and simply want to remove rendered events from the scheduler?
If so try replacing

if (info[i] != tid) scheduler.deleteEvent(info[i]);
with

if (info[i] != tid) scheduler.deleteEvent(info[i], true);
onBeforeEventDelete event won’t be called, dataprocessor will stay still and hopefully this will be faster.

Another option:

if (info[i] != tid) { delete this._events[info[i]]; this.unselect(info[i]); } scheduler.setCurrentView(scheduler.getState().date, scheduler.getState().mode);
Hope this helps :slight_smile:

Best regards,
Ilya

#8

You understood perfectly Ilya. Database-wise, everything was gone, I was just trying to remove the rendered events from the scheduler and:

scheduler.deleteEvent(info[i], true);

did the trick perfectly.

Thanks a lot :slight_smile:.

Osu