Redning af fejlloadede rammer

Den virker perfekt for mig. Bruger IE 5.0.

Det er muligt at du har en fejl i din browser, eller at det er et cache problem...
hvis det er det sidste kan du altid prøve at appende noget (new Date()).getTime() til en query-string.

Og min IE 4.0 ser også ud til at virke ret så konstant.
Men på Netscape 4.7 går det som sagt galt ca hver 10-ende gang.
Hvorfor?

stringbuffer >> Hvad fortæller  (new Date()).getTime()  mig? udover hvornår det gik galt?

den giver bare et tal, der er afhængig af dato og derfor forskellig hver gang. Dvs at selv hvis browseren lægger siden i cache, vil den ikke genkende url´en hvis den indeholder sådan noget, og derfor vil den hente den hver gang.

Forresten udfører min netscape 4 en ulovlig handling når jeg forsøger at lege med din side.

lortebrowser... hvad kan jeg allers sige

Smart med datostreng på urlen. skal huske. tak.

men \"lortebrowser\" er ikke rigtig nok. Der må være noget grund når den ene eller den anden brovser laver skidt. Og en måde at arbejde sig udenom.

Men dit input hjalp. Jeg gik tilbage i NS3 og prøvede og fik en fejl med at querystrengen var blevet cuttet efter main=http:  ...  Illegal URL method.

Det kunne ligne at jeg skal escape og unescape de urler der sendes med query.

Her er et par ting, der lige stødte mig lidt...
istedet for java script:void() prøv at bruge java script:\'\' eller java script:{} - ikke alle browsere kender void()

istedet for at bruge komplicerede løkker til at parse din search-string kunne du evt prøve det her:
var query;
if (query = location.search)
eval(query.replace(/(\\?|\\&)(\\w+\\=)(\\w*)/g,\';$2\\\'$3\\\'\'))

har aldrig selv brugt
location.replace(url)
bruger altid
location = url
det virker i alle de sider, jeg har lavet til NUTSCAPE

nå ja... Netscape er jo oz meget hård mht reserverede ord. man skal passe på med ord som name osv... og det med illegal characters i URL og win handles går også nemt galt.

Curiouser and curiouser.

Escape & unescape gør den rocksteady i NS3. Men NS4.7 laver stadig samme nummer, ca hver 10-ende gang.

og jeg ved godt at man kan have lange diskussioner om hvorfor Nutscape er eller ikke er en skodbrowser. Men det stærkeste argument må være at Nutscape er kodet så tumpet at det tillader stack-overflows, ugyldige sidefejl, og andre ulovlige handlinger, som ikke bare får den til at crashe men nogle gange gør det umuligt at bruge nutscape igen før man genstarter computeren.

*we only come out at night...*

Men komplicerede løkker kan jeg forstå. Jeg er kun lige begyndt at snuse til regular expressions.
Indtil videre har jeg haft fine erfaringer med replace(url), og man slipper for en frustreret bruger der prøver at bruge back til at komme forbi den side der sender ham frem igen hvergang han trykker.
Men rigtig det må testes.
Og som du nævner navnesammenfald, både rammer og searchparametre hedder menu og main, og det er heller ikke \"sikre\" navne.

Men indtil videre bare iseng og sove, jeg er ved at lave formange slåfejl.
Håber at accepte imorgen (gør det unner alle omst. stor hjælp. tak)

mvh JakobA

Jeg tror den er ved at komme nærmere. Betingelsen i if-sætningen:

if ( ( ( parent!=self )
    &&( parent.frames.minMain )
    &&( parent.frames.minMain!=self )
    )
  ||( ( parent==self)
    &&( ( \'\' == location.search )
      ||( location.search.indexOf(\"noframes\")==-1 )
  ) ) ) {
  top.location.replace( myFrame +\"?menu=\"+escape(myMenu) +\"&main=\"+escape(self.location.href) );
};

virker nogengange og nogengange ikke.
hvis jag ændrer til:

if ( ( ( parent!=self )
    &&( parent.frames.minMain )
    &&( parent.frames.minMain!=self )
    )
  ||( (parent==self )
    &&( location.search )
    &&( ( location.search == \'\' )
      ||( location.search.indexOf(\"noframes\")==-1 )
  ) ) ) {
  top.location = myFrame +\"?menu=\"+escape(myMenu) +\"&main=\"+escape(self.location.href);
};

virker den ALDRIG. Men ifølge javascript ref v1.3 skal man altid få true når man tester på en eksisterende variabel (her:  ( location.search ) .
(anden test ligget pt i expframesmain0.html)

så min pt teori er at location.search i virkeligheden slet ikke er en variabel, men snarere en funktion med sideeffekter som prøver at opføre sig fornuftigt alt efter hvor den står (og altså fejler her)

Det ku ligne en specifik Netscape bug, men der må da være en vej udenom. dvs en måde at teste om search strengen er tom, og om den indeholder strengen \"noframes\".

Det har ikke noget at gøre med hvordan man ændrer location. begge måder er lige effektive. De virker hver gang, forudsat man beder dem om det, og det gør scriptet åbenbart ikke.

well, men kan ikke i alle browser- og javascriptversioner være sikker på hvad der har typen string og hvad der har typen object. Nogle gange kan man løse problemet ved at sige
\"\"+minVar == \"\" istedet for minVar == \"\"

Men egentlig burde du ikke behøve at teste for den, da en tom streng burde være opfattet som null.

Det er måske det der skal til  == null  i stedet for  == \"\"

Men desværre gir
  if ( ( parent==self )
    &&( ( self.location.href.indexOf(\"?\")==-1 )
        ||( location.search.indexOf(\"noframes\")==-1 )
    )  )
præcis samme fejl og ligeså nu og da. Det var nok et vildspor.

Det burde også være muligt at få filnavnene ind i framesettet. Ikke bare lægge dem ind via onLoad()

prøv evt

<frame name=minMenu src=\"java script:this.src=myMenu\">

har ikke testet det, bare en tanke...

det med at give rammen samme navn som din variabel kan iøvrigt også drille i nogle tilfælde.

Næ Næ, jeg har passet på. rammen = minMenu, variable = myMenu. feltid i searc-streng = menu.  så det er ikke der.

Heller ikke
<frame name=minMenu src=\"java script:this.src=myMenu\">
<frame name=minMenu src=\"java script:this.src=top.myMenu\">
<frame name=minMenu src=\"java script:this.location=top.myMenu\">
<frame name=minMenu src=\"java script:this.location.href=top.myMenu\">
<frame name=minMenu src=\"java script:void(this.location.replace(top.myMenu))\">
<frame name=minMenu src=\"java script:top.frames.minMenu.location.replace(top.myMenu)\">
Det bliver til ret mange mulige kombinationer. Alt ialt.

<frame name=minMenu src=\"java script:top.frames[0].location =top.myMenu\">
virker i IE men ikke i netscape

med en alert lige foran
  alert (\"filen reloades med: \" +myFrame +\"?menu=\"+escape(myMenu) +\"&main=\"+escape(self.location.href) );
  top.location.replace( myFrame +\"?menu=\"+escape(myMenu) +\"&main=\"+escape(self.location.href) );
har jeg een gang fanget den lige før den \'gik galt\' så den kommer så langt.

Så flyttede jeg den alert om BAGVED ændring af location:

  var myURL = myFrame +\"?menu=\"+escape(myMenu) +\"&main=\"+escape(self.location.href);
  top.location = myURL ;
alert( \"loaded \"+myURL );

og det gik godt. igen og igen, (og alerten blev udført), indtil jeg kommenterede alerten ud

  var myURL = myFrame +\"?menu=\"+escape(myMenu) +\"&main=\"+escape(self.location.href);
  top.location = myURL ;
//  alert( \"loaded \"+myURL );

Så gik den død igen. Det ku tyde på en race af en art.
At denne side bliver ved at loade en tid efter at dens location er blevet ændret. Og så skriver i munden på den anden og nogengange vinder. Men så burde AL linking via location jo være risikabel.

yepsi. med:

  var myURL = myFrame +\"?menu=\"+escape(myMenu) +\"&main=\"+escape(self.location.href);
  top.location.replace ( myURL );
  for (i=0; 20>i; i++) for (j=0; 20>j; j++) ; // kludge delay. Må kunne gøres bedre
//  alert( \"loaded \"+myURL );

med den delayløkke inde har den nu virket 30 gange i træk uden problemer

tak

for søren do osse :)

Lokalt på PC-en virker det. men kørt fra server går det i uendelig løkke på NS4.7.

Hvad /(\\?|\\&)(\\w+\\=)(\\w*)/g,\';$2\\\'$3\\\'\') er det der foregår?

Nej. Det var min egen bøf. Testede på \"hedder denne ramme mu også minMain\" i menu siden.

Men fra server er den gode gamle \"nogen gange går det galt\" fejl der igen.

nu skulle den være der :-))
http://hjem.get2net.dk/Jakob.Aggernaes/temp/expframe.html