dmcdivitt

I do this by placing an ID in each table, assigning each to a variable with getElementById, then calling a javascript function on each cell of the first row of each table. var adj=0; var inc=0; function match(ea,eb) { var fix,comp; inc++; if (ea.clientWidth<eb.clientWidth) { comp=eb.clientWidth-adj; ea.innerHTML="<div id='m"+inc+"' style='width:" + comp + "px;'>" + ea.innerHTML + "</div>"; fix=ea.clientWidth-eb.clientWidth; } else { comp=ea.clientWidth-adj; eb.innerHTML="<div id='m"+inc+"' style='width:" + comp + "px;'>" + eb.innerHTML + "</div>"; fix=eb.clientWidth-ea.clientWidth; } if (fix!=0) { adj+=fix; comp-=fix; var ob=document.getElementById('m'+inc); ob.style.width=comp+'px'; } } hh=document.getElementById('head'); nn=document.getElementById('names'); dd=document.getElementById('detail'); hta=document.getElementById('htab'); dta=document.getElementById('dtab'); nta=document.getElementById('ntab'); mna=document.getElementById('mna'); for (var j=dta.rows[0].cells.length-1;j>=0;j--) match(hta.rows[0].cells[j],dta.rows[0].cells[j]);

I changed an edit screen to appear as a pop-up window. Previously everything was being done in the same window with too much navigation back and forth. Unfortunately I cannot stream a file to the desktop if invoked from a pop-up window. If I invoke the page directly by entering a URL address, it will stream a file to the desktop, but if rendered as a pop-up, when an attempt is made to stream a file, nothing happens. Streaming a file to the desktop is done as follows: header("Content-disposition: attachment; filename=$filename"); header("Content-type: document/pdf"); readfile($filename); return; This causes an open/save/cancel dialog to appear in the browser. Help would be appreciated. The browser used is IE. I can't try Firefox, since IE must be used for the ActiveX functionality, so I don't know if other browsers have a pop-up window limitation. Anyway, I have to make it work in IE. Thanks

The problem I was having was a result of pages being cached in the browser. It was only by chance I got it to work at all! I assume I just happened to refresh the page I was testing with, otherwise it wouldn't have worked. Following that some pages were working and others not. When I reset the cache everything worked.

RESOLVED I uninstalled PHP that was done via msi file, unzipped the PHP zip file to c:\php and placed the following in Apache config: PHPIniDir "C:/php/" LoadModule php5_module "C:/php/php5apache2_2.dll" I had the AddHandler line too, but upon trying without it I left it commented out. Apache says all virtual paths are scripted by default which is why the AddHandler isn't necessary. Having Apache read PHP from c:\Program Files is identical to c:\php. As mentioned earlier the PHPZ extension was working so that proves PHP was working. I like doing the zip version better because no install/uninstall is necessary. All that's required is to replace files at c:\php. I don't know what fixed the problem but I'm not going to worry about it.

No. I have an application defined as follows. If I put the PHPZ file there it works. #php Alias /php "C:/websites/php" <Directory "C:/websites/php"> Options FollowSymlinks Indexes Order allow,deny Allow from all </Directory>

I've never had an issue with the MSI installer package before. I did try something which had an effect. I change the Apache config to the following: #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir "C:/Program Files/PHP/" LoadModule php5_module "C:/Program Files/PHP/php5apache2_2.dll" AddHandler application/x-httpd-php phpz php #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL This told it to use the file extension PHPZ in addition to PHP. That worked. If I rename a .php file to .phpz, the script runs properly. It won't run as .php though. I will download the zipped version of PHP and see if that makes a difference. I don't think it will though.

Yes, I stopped and started the server each time. Just now I tried changing to CGI instead of Apache module. No difference. The PHP extension does not seem to be recognized or it's being masked, but I don't see how. IIS is running on another PORT. All my ASP.NET applications run through the Apache server fine via mod_aspdotnet, so the Apache server is recognizing and processing different file extensions. When I install PHP I don't use the IIS option but one of the Apache options.

<?php phpinfo(); ?>

My machine was reimaged and I had to reinstall everything. Now I can't get PHP to process any scripts. The scripts are displayed as if a text file. This morning I uninstalled PHP and Apache and reinstalled. My Apache config file has: #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir "C:/Program Files/PHP/" LoadModule php5_module "C:/Program Files/PHP/php5apache2_2.dll" #AddType application/x-httpd-php .php #AddHandler application/x-httpd-php .php #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL I've tried with and without AddType and AddHandler. I have Win XP SP3, Apache 2.2.15, and PHP 5.3.2 installed as Apache module. Also I have IIS 5.1 running on port 82. I need that for classic ASP pages. Everything was working fine before my machine was reimaged. Help please!

Taken from http://wiki.whatwg.org/wiki/FAQ#Under_what_conditions_should_a_DOCTYPE_be_used_in_XHTML.3F . There are many references, but this one is worded well. Words at the bottom are most significant. Will (X)HTML 5 finally put an end to the XHTML as text/html debate? Yes. Unlike HTML 4.01 and XHTML 1.0, the choice of HTML or XHTML is solely dependent upon the choice of MIME type, rather than the DOCTYPE. See HTML vs. XHTML What will the DOCTYPE be? In HTML: <!DOCTYPE html> In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents. For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead. <!DOCTYPE html SYSTEM "about:legacy-compat">. Note that this is not intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only. Excluding the string "about:legacy-compat", the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <!DOCTYPE HTML> or <!doctype html>. These alternatives were chosen because they meet the following criteria: * They trigger standards mode in all current and all relevant legacy browsers. * They are well-formed in XML and can appear in XHTML documents. * It is possible to output at least one of the alternatives, if not both, with extant markup generators. * They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML. * The first is short and memorable to encourage its use. * The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use. Under what conditions should a DOCTYPE be used in XHTML? Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do: 1. The document is intended to be a polyglot document that may be served as both HTML or XHTML. 2. You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.) 3. You wish to use a custom DTD for DTD-based validation. But take note of what's wrong with DTDs.

Hi MATE. How are you? The point is, all browsers except IE use the most current standard. Until IE8, IE would also use what was current. Using the meta tag tells IE to use what's current. When a DOCTYPE is used, the browser is forced to figure out what set of rules and what may or may not work. Browsers work differently and implement differently. Without a DOCTYPE a page is not locked to anything and the latest technology is always used. The only time a DOCTYPE is needed and should be used is when a page is being made with very narrow scope and must implement a subset of the standard. Just because I say something different than you does not make what I say invalid, nor does it give you cause to use strong language to make your point. People can look it up and read about it like I have done. As is appropriate in this forum, I posted my solution so my problem can be shown to be solved.

try: var s = whatever; s = s.replace('<','<').replace('>','>').replace('&','&');

I think I have this fixed. The problem was IE8 and not Vista, but Vista of course has IE8. I have IE8 on my XP machine but I guess did not have it configured so as to create errors. Adding the following meta tag in the header solves everything: <meta http-equiv="X-UA-Compatible" content="IE=edge" /> Why the meta tag and not a doctype? According to the flowchart at http://blogs.msdn.com/giorgio/archive/2009/02/16/ie8-meta-tag-site-compatible.aspx , the doctype offers no guarantee of anything. If a doctype was used, the meta tag would still be needed to force use of the most current IE engine. Also, telling IE to use "edge" is the only certain course to the most current IE engine. Other browsers default to the current engine when there is no doctype. Only IE does not. For standard HTML a doctype should not be used to obtain the best compatibility for all browsers, but the IE meta tag should always be used. After using the IE meta tag on my page, it did begin throwing a javascript error with debugging turned on. I got rid of the error. I still don't know why my IE8 was working and some others were not, prior to use of the tag. The error I saw only came to exist because of strict mode, caused by presence of the tag, which wasn't the case before. I will continue making my pages without a doctype, but will from now on always include the IE meta tag, too.

Yes, but you can use one PHP file for all of it. When the script begins executing, check $_POST["button"] to see if it has a value. If yes, that means the page has already been rendered and someone clicked a button on the page. You can also use $_POST["usertext"] to obtain the text the user entered. You would then just stream a text file back out to the client and not output an HTML page. Otherwise, output the HTML page from your PHP script in the normal fashion, and when you output the page, be sure and include the form element, button, and text box. The action or URL of the form element should be the same PHP script.

You are using "text" as a variable. Somewhere in javascript you must have a statement saying: var text = whatever; Seeing "text" as an attribute inside one of the HTML elements does not also make it a javascript variable. If there was a div tag it might have the id of "xyz". To write to the innerHTML you would then use: document.getElementById("xyz").innerHTML = "great happiness"; There's a difference between javascript and stuff you see inside HTML elements.

What is "text"? That is not a variable name. That is an attribute of one of your elements. You were making the same mistake with "value".

Call the elements chkEpisodes without the "[]". Only one can be selected at a time if done properly. Give them all the same name, but different value attributes: 1,2,3. You don't have to set the id attribute. In the onsubmit event for the form put "return rtest();" Make a javascript function called rtest() and in the function sample formname.chkEpisodes.value. If not set, return from the function with a false value, otherwise return with a true value. return false; return true; When false is returned within the onsubmit event, the event will be canceled. You might add an alert inside the rtest() function telling the user to select a value.

Use the onclick event and submit the form, but on the server side do not write a page. Instead do the following in PHP: header("Content-disposition: attachment; filename="whatever.txt"); header("Content-type: document/text"); - echo your lines ending each with "\r\n"; return; This will cause a view/save dialog to appear at the client. Be sure and use return to kill the script so no additional output can occur such as an extra linefeed after the PHP close tag.

You are not setting the variable with the name "value". When "value" is used in the html element it is an attribute of the element. But you are using "value" as a named variable in javascript and not initializing it or assigning anything to it. I suggest changing the calc function as follows: function calc(v){ if(v== "qualifier") qualifier(); else if (v== "sr") sr(); else if(v== "snr") snr(); } change the HTML elements as follows: <input type="radio" name="typeofbet" id="typeofbet" onclick="calc('qualifier');"><br> <input type="radio" name="typeofbet" id="typeofbet" onclick="calc('sr');"><br> <input type="radio" name="typeofbet" id="typeofbet" onclick="calc('snr');"><br> Notice the use of double quotes and single quotes. It is best to use double quotes when assigning attributes within elements, and using single quotes where literals are needed. The value attribute is no longer being set in the HTML element, but is being passed as an argument to the calc function. The onclick events do not need to return anything so remove the "return". You only need to have an event return a value if you want to kill it, preventing it from bubbling through to other events, and in that case you want to return FALSE. Reduce the amount of stuff you type, yet keep it legible, since all must be sent to the client. Do not use comments which simply say what can easily be understood by looking at the code. Use comments to answer questions such as "why am I doing it this way" or quirks being circumvented.

There's a moralist in every crowd.

The best way to resolve cross browser support with <!DOCType is to not use it.

I found the onload events do not always work. I suggest putting a small piece of javascript at the very bottom of the page, just before the closing body tag. In that javascript start a timer, and the timer of course can execute a function anywhere else in the page. Placing javascript at the very end of the page works better than onload events in my experience, but you should only do a few instructions in that manner. When the timer fires you can unhide the image. What you might also do is put the image inside another element and give the other element width and height, the same as the image should have when loaded. That will keep the image from reflowing the page after it has rendered. The image should finish loading pursuant to the original event thread. If the timer fires before the entire image is downloaded, the image will simply continue to download and fill in.

I've never had a problem with getElementById. I was never able to get getElementByname to work very well. For the elements you want to denote, set the name and id tags the same all the time. If there is a form, you should always be able to access that by formname.elementname.value without having to use getElementById. There is no need to use the <!DOCTYPE declaration. I read an article to that effect which said it is ignored for the most part. Always use <head, </head, <body, and </body.

I will try the onclick event and see if that improves things. I should be able to use the same anchor tags, but set href to "#" and have onclick return a false value. If that fixes the problem it will be a good thing to know for sure.

I was the webmaster of the site but gave it away, and the appearance changed, so that is not mine. Since then I put some PHP on the site. The problem application can be found at: http://www.spfldcycling.org/miles/om_login.php . The problem seems fairly straightforward. Javascript doesn't work for everyone. I assume the people who are having problems use IE. Basic FF does not block javascript, and if they did install FF and change it, they'd have enough sense to know why the application doesn't work. Two people contacted me with the same problem and knowing them, I'm sure they use IE, because they use the machine exactly as it comes out of the box. I would post the PHP code, but that seems pointless, because the problem is with HTML that's not functioning properly in the client. That HTML can be seen by looking at the page source. I can post the PHP code, but would have to include three files. My pages do not contain line feeds in the page source, so the source may be difficult to read. If I have a simple href "javascript:docommand('whatever');" on an anchor, that should work if javascript is enabled. What more is there? I've checked the page on the client side for syntax errors by turning on script errors in IE, though I have XP. I'm thinking Vista has a new setting or something, that XP does not have, and therefore javascript is not working. Thank you for entreating me.