Het hol van de Code

Ik heb twee veranderingen in de Vormen aangebracht en Gebied lister postte ik gisteren - de originele post is veranderd om hen te omvatten.

Vooral, werd de lijn aan deeg in Start->Run om het programma in de registratie te installeren veranderd door WordPress. Hoewel de tekst identiek keek, werden de dubbele citaten veranderd in een verschillend karakter. Het resultaat was u zou ontvangen een „ongeldige zeer belangrijke naam“ fout. Als, in Dos, u terugging en dubbele citaatimposters met daadwerkelijke dubbele citaten verving, zou het boete in werking stellen. Zo heb ik dat lijn met PRE en TT markeringen in de originele post verpakt en een partijdossier verstrekt voor het geval dat iedereen nog problemen heeft.

Ten tweede, ontdekte men dat sommige computers van Vensters popup zouden blokkeren. Er zou geen gegeven fout of om het even welke aanwijzing zijn van wat voorbij een dialoogdoos gebeurde die omhoog op het scherm en het verdwijnen opvlamt. Ik zuiverde dit door waakzaam toe te voegen (1), waakzame (2)… waakzame (n) berichten na elke lijn van de broncode. Zodra ik dat deed, D.W.Z. vriendelijk genoeg was om me te vertellen dat het uit wegens de „bombardeerde Toegang wordt“ fout ontzegd die van mijn Window.Open wordt teweeggebracht (““,“ tcc_formlist“,““); bevel. Die lijn werkte op mijn kantoor, maar bombardeerde uit op één van mijn huiscomputer.

De reden is dat de Vensters nu één venster of kader tot een ander venster toegang hebben of kader die blokkeert dat in een verschillend domein (of veiligheidsstreek die ik heb geloofd) is. Deze techniek is vraag DwarsKader Scripting. Het probleem is dat wat ik met deze hulpmiddelen doe precies over twee kaders/vensters werkt. Gelukkig is er een manier rond dit.

Beschikbare JavaScript mini-FAQ, hier: http://www.dannyg.com/ref/jsminifaq.html#q15, heeft een goede beschrijving van deze kwestie en het werk rond:

Q. Wat D.W.Z. „Toegang wordt ontkend“ fout betekenen?
A. De „toegang Ontkende“ fout in om het even welke browser betekent gewoonlijk dat een manuscript in één venster of kader probeert om tot een ander venster of kader toegang te hebben het waarvan domein van het document van het document dat het manuscript bevat verschillend is. Wat over dit oneven kan schijnen is dat u deze fout in D.W.Z. voor Vensters vaak krijgt wanneer een manuscript in één venster een nieuw venster (met window.open () produceert), en de inhoud voor dat wordt ander venster dynamisch van het zelfde manuscript gecreërd dat het openen doet. De nadruk () methode brengt ook de fout teweeg.
De fout kan ook voorkomen als de manuscripten proberen om tot voorwerpen, eigenschappen, of methodes toegang te hebben die neer door de veiligheidspeloton van Microsoft zijn gesloten. Bijvoorbeeld, was het bezit document.styleSheets.rules toegankelijk in D.W.Z. 5 en D.W.Z. 5.5, maar is niet in D.W.Z. 6.

Voor het nieuwe vensterprobleem, is er een beetje van geschiedenis verbonden aan het probleem en de alternerende actie. Bijvoorbeeld, vaak voor komt het probleem wanneer de manuscripten van de lokale harde schijf in werking worden gesteld. U krijgt een aanwijzing over de situatie in titlebar van het nieuwe venster: Het dwingt ongeveer: lege URL aan het nieuwe venster, dat een protocol is: domein dat verschilt van waar het manuscript van uw hoofdvenster uit komt. Als, echter, u het zelfde belangrijkste vensterdocument op een server, zet en tot het via http: toegang hebt, gaat het probleem weg.

Er is een alternerende actie voor het lokaal-enige probleem: In de eerste parameter van de window.open () methodevraag, laad een echt document (zelfs als het een tevreden-vrij HTML- document) is in het sub-venster alvorens document.write () te gebruiken om inhoud voor subwindow te produceren. De ladingsactie `wettigde het venster zoals komend uit het zelfde domein zoals het document van uw hoofdvenster.

(Deze oplossing beïnvloedt geen manuscripten die een pagina van een veilige server in een afzonderlijk venster of een kader laden. Een HTTP: protocol in één venster en https: in ander-gelijk als van de zelfde server.domain-opbrengst een Ontkende veiligheidswanverhouding en „een Toegang.“ Het plaatsen van de eigenschappen document.domain van beide pagina's kan het probleem (maar ik kan het zonder twijfel testen niet) oplossen.)
[...]

Ik heb de originele code bijgewerkt om deze moeilijke situatie te omvatten.
Window.Open (““,“ tcc_formlist“,““);
is nu
Window.Open (“ file:///c:/Windows/web/formlist.htm“,“ tcc_formlist“,““);

Het eindresultaat is dat het bevel window.open snel het manuscript opent alvorens de dynamische inhoud wordt getoond. Deze kleine echo is niet merkbaar op mijn dochterscomputer. Ik denk niet het een belangrijke vertraging zal zijn. wegens hoe de code wordt geschreven, wordt het geheel van de routine JS niet uitgevoerd. Grootste negatief is dat het manuscript nu een verwijzing heeft naar wat ik het dossier verwacht - noem om op uw computer te zijn. Als u het manuscript anders noemt, moet u die verwijzing in de bron veranderen. Ik betwijfel vele mensen het manuscript anders zullen noemen.

Dat was vriendelijk-van een wandeling… Ontdekt het dat al merk?