hadoob024

Perfect! That works!

Quick question then, that script that builds the PDF takes a couple of seconds to run. Is there something that I could do so that after the user clicks on the button, they don't click on it again until the whole process runs? I wonder if that's why the window.close was put in.

Cool! Thanks for the tips! Quick follow-up, I can do a couple of window.location calls back to back, right? Christian F. resolved my issue by telling me to remove the "Javascript:" from my onclick call, and that seemed to work. Yeah, I'm more of a backend programmer than a front-end developer. This issue was just kinda dropped into my lap the other day

Thanks! Yeah, I'm so used to Firefox/Firebug and Chrome/Chrome Developer Tools. Haven't had a chance to really play around with IE and its developer tools.

First off, thanks for the help! That's what I thought too, but it's weird because in my original code, the window.location does run (because the PDF gets generated). It's just the window.open that never executes. And this is only in IE. Everything runs through properly in Firefox.

That did it! My original code still doesn't run properly (the window.open() never executes), but that rewritten one does run! That's the plan. Just trying to get it to work first before tidying up stuff. Nope, no particular reason. I didn't know about window.location.replace(), so I thought I had to do it that way (close window, generate PDF, open new window showing remaining PDF's that can be created). Any thoughts about why the first way doesn't work in IE, but works in Firefox?

In a popup, I have a button. Here's how I defined the button: <input type="button" name="generatePO" value="Z-PO" onclick="Javascript:window.close();window.location='index.php?module=Patient_Procedure&action=genMFGPO'&pomode=create&kindofpo=Z';window.open(\'index.php?module=Patient_Procedure&action=genMFGPO&pomode=preview','poverifywin','width=1250,height=1000,status=0,resizable=1,scrollbars=1,toolbar=0,menubar=0,location=0')"> Basically, what it does is, close the popup, execute that window.location call which creates a PDF, then executes window.open() to open another popup to see if there are any more PDF's that can be created. This works fine in Firefox, but that window.open() never gets executed in IE 9. Tried some google searches, but nothing came up. I've rewritten this several times and can't get it to work in IE 9. Here's one of my rewrites: <input type="button" name="generatePO" value="Z-PO" onclick="Javascript:window.location='index.php?module=Patient_Procedure&action=genMFGPO'&pomode=create&kindofpo=Z';window.location.replace('index.php?module=Patient_Procedure&action=genMFGPO&pomode=preview');"> For some reason though, the window.open() doesn't get executed unless I click on the button twice. Can't think of how to fix this for IE. Thoughts???

I think mgmt just decided to change the way we're doing it. Instead of requesting a token from the Document server, we're going to generate a token (during the login process) and then send that to the Document server. If the server's down, then the login process can still continue and users can use the system (minus being able to access documents). But since we're not asking for a token but generating it and sending it ourselves, we won't have this issue in the future. I was in charge of a band-aid fix prior to this change going in (sometime this weekend). Hopefully it works <wishful thinking>

Not sure, but I know that you can't ping the server. It won't send back a response. Yeah, I think I found something here that might work: http://www.darqbyte.com/2009/10/21/timing-out-php-soap-calls/ Yup. I think mgmt realized this too and are working to change the way these servers are setup. They just wanted a band-aid fix in the meantime. I'm wondering if it's even worth the time to implement the solution from above if this is going to change anyway.

Hmmm... Cool. I was dreading what you said but kind of expected it. Will keep looking into it though. Thanks though!!!

I was thinking about something like that, but realized that it's not the require_once() function I'm worried about. It's the execution of the getToken() function that causes the issue. Like if I did something like: $token=@getToken(); If the Document server is down, and getToken() is making a SOAP call to this server, will that result in a FATAL error? If so, will adding the error suppressor let the code continue running?

I'm not allowed to modify the function getToken(). I can only modify that block of code from above: require_once('include/utils.php'); $token=getToken();

Interesting. Yeah, I know it's not the require_once() that's failing because it's done locally. It's the getToken() function that actually makes the call to our Document server. The Document server then sends a unique token back. We then build the links to our documents using this token. The issue is that if that Document server goes down, we never get that token sent back. And this getToken() routine is called at the end of our logging in process, so if this routine gets hung up because the Document server went down, the login process never completes. Does that make it more clear? What I want to do is make it so that if the Document server goes down, and the getToken() function fails, I want the script execution to continue. This will allow the user to continue to operate in the website (minus access to the documents). Two follow-ups, the error suppressor doesn't work against FATAL errors, does it? Also, I don't think we're allowed to PING that server. Any other thoughts? Thanks!

I have this one issue. While logging in into our system, we call a routine called getToken(). This calls a routine on another server (used to be able to securely access documents). The issue we have is if that other server goes down, this call fails, and the user isn't able to login. I want to make it so that even if the other server goes down, users can still login and access our system (just not documents). I know that I can't prevent fatal errors or even ignore them, correct (even with set_error_handler)? Any thoughts? It's a simple call, here's all it is: require_once('include/utils.php'); $token=getToken();

I believe that when I'm letting Sugar handle the save through the bean, that I need to have the date in the format of the user's setting. Sugar then knows what the format of the value that it's getting and converts it according to our db format which is "Y-m-d H:i:s". Only when I do a direct UPDATE to the db do I actually put the format in "Y-m-d H:i:s", otherwise I just need to let Sugar know what the date format of the user is. I even created a tmp table where I'm dumping all this info to see what's getting generated and what's getting saved. I set this up: $bean->status_date = date($date_format); $test_query = "INSERT INTO tmp_date_data(proc_id, query, server_name, modified_user, status_id, new_status_id) VALUES('".$bean->id."', '".$bean->status_date."', 'web3', '".$bean->modified_user_id."', '".$row['mystatus']."', '$statusid')"; $test_query_result = $db->query($test_query); And looking at the results it's weird, because in every case (of where the bad date value gets stored), "$bean->status_date" has the correct value, but the value that gets saved is either 1/1/1970 or 12/31/1969. I'm pretty stumped on this one.