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.