Horizontale sub-menu's verschijnen achter adobe

[pbd4499]

CssHunter, dus ik hoef alleen maar het CSS gedeelte aan te passen en het stukje code van Hack for IE in mijn css te verwerken?

Het is bij ons iets anders opgebouwd via swmenupro en ze gebruiken daar niet u1 & li maar divs & tables. :evil:

Het is me nu nog niet duidelijk onder welke kop ik hem dan dien te plaatsen:

.transMenu69
{
 position:absolute;
 overflow:hidden;
 left:-1000px; 
 top:-1000px; 
}
.transMenu69 .content {
 position:absolute  ; 
}
.transMenu69 .items {
 border: 0px solid #FFFFFF ; 
 position:relative ; 
 left:0px; top:0px; 
 z-index:1020; 
}
.transMenu69  td
{
 padding: 5px 5px 5px 5px !important;  
 font-size: 10px !important ; 
 font-family: Arial, Helvetica, sans-serif !important ; 
 text-align: left !important ; 
 font-weight: bold !important ; 
 color: #565959 !important ; 
} 
#subwrap69 
{ 
 text-align: left ; 
}
.transMenu69  .item.hover td
{ 
 color: #FFFFFF !important ; 
}
.transMenu69 .item { 
 text-decoration: none ; 
 cursor:pointer; 
 cursor:hand; 
}
.transMenu69 .background {
 background-color: #FFFFFF !important ; 
 position:absolute ; 
 left:0px; top:0px; 
 z-index:1020; 
 opacity:0.85; 
 filter:alpha(opacity=85) 
}
.transMenu69 .shadowRight { 
 position:absolute ; 
 z-index:1020; 
 top:-3000px; width:2px; 
 opacity:0.85; 
 filter:alpha(opacity=85)
}
.transMenu69 .shadowBottom { 
 position:absolute ; 
 z-index:1020; 
 left:-3000px; height:2px; 
 opacity:0.85; 
 filter:alpha(opacity=85)
}
.transMenu69 .item.hover {
 background-color: #6BA6DE !important ; 
}
.transMenu69 .item img { 
 margin-left:10px !important ; 
}
transMenu69 iframe {
position: absolute;
z-index:1010;
filter:alpha(opacity:0.1);
}
table.menu69 {
 top: 0px; 
 left: 0px; 
 position:relative ; 
 margin:0px !important ; 
 border: 0px solid #FFFFFF ; 
 z-index: 1020; 
}
table.menu69 a{
 margin:0px !important ; 
 padding: 5px 5px 5px 5px !important ; 
 display:block !important; 
 position:relative !important ; 
}
div.menu69 a,
div.menu69 a:visited,
div.menu69 a:link {
 font-size: 10px !important ; 
 font-family: Arial, Helvetica, sans-serif !important ; 
 text-align: left !important ; 
 font-weight: bold !important ; 
 color: #565959 !important ; 
 text-decoration: none !important ; 
 margin-bottom:0px !important ; 
 display:block !important; 
 white-space:nowrap ; 
}
div.menu69 td {
 border-right: 1px solid #FFFFFF ; 
 border-top: 1px solid #FFFFFF ; 
 border-left: 1px solid #FFFFFF ; 
/* background-color: #FFFFFF !important;  */
} 
div.menu69 td.last69 {
 border-bottom: 1px solid #FFFFFF ; 
} 
#trans-active69 a{
 color: #FFFFFF !important ; 
 background-color: #6BA6DE !important ; 
} 
#menu69 a.hover   { 
 color: #FFFFFF !important ; 
 background-color: #6BA6DE !important ; 
}
#menu69 span {
 display:none; 
}
#menu69 a img.seq1,
.transMenu69 img.seq1,
{
 display:    inline; 
}
#menu69 a.hover img.seq2,
.transMenu69 .item.hover img.seq2 
{
 display:   inline; 
}
#menu69 a.hover img.seq1,
#menu69 a img.seq2,
.transMenu69 img.seq2,
.transMenu69 .item.hover img.seq1
{
 display:   none; 
}
#trans-active69 a img.seq1
{
 display: none;
}
#trans-active69 a img.seq2
{
 display: inline;
}

 

[csshunter]

Ho, nee, nu geloof ik dat het toch verkeerd gaat.
De SpryMenu-css werkt alléén zo, omdat er een Spry.javascript aan vast zit, dat de zaak bedient.

Als je een heel ander menusysteem gebruikt zoals Swmenupro, dan kan je misschien wel met enige moeite de styles van het Sprymenu overnemen. Maar daarmee heb je het nog niet aan de praat, als je niet tegelijkertijd een aangepaste versie van het javascript gebruikt.
De Spry-oplossing staat of valt immers met de combinatie van de css en het javascript.

En ik ben geen javascript-held genoeg (= helemaal geen held in javascript) om het IE-HACK gedeelte uit het Sprymenu in te bouwen in het script van Swmenupro (als dat tenminste via een script draait; anders moet het een los script worden).

Ik kwam wel tegen dat Adobe zelf beweert dat het niet kan:

"The plugin does not allow HTML content to overlap its own content.
Design the page's content so that layers or pop-up menus do not overlap form elements or embedded content."

Dat staat tenminste in een document uit 2004, en of dit in de moderne tijden ook nog geldt, vertelt het verhaal niet er niet bij.
-Voor Flash klopt het in elk geval niet meer, want daar kan je met een parameter opgeven dat je er overheen mag.
-Bij de Pdf-parameters (werking en overzicht) kwam ik zoiets niet tegen.

Ik zie het dus in Firefox, Chrome en Opera (samen toch een redelijk marktaandeel!) dus voorlopig niet lukken.
Dus als je organisatie/bedrijf hardop besluit de gebruikers van Firefox, Opera en Chrome buiten te sluiten van het menu (en daarmee van de site), dan kan je de IE HACK van het Sprymenu gaan proberen toe te passen.
Maar dat zou ik dus nooit doen! *)

Wat dan wel?

• Tja, misschien een Tabjes-oplossing voor de submenus i.p.v. uitrollen? Met zoiets als deze zou je bv. een heel eind kunnen komen.
• Of een lampion-idee met een menu aan de zijkant, waarbij de lampion in- en uit harmonica't met ertussen de submenu's?

Sterkte!
CSShunter

*) Behalve als het om een intranet gaat, waarin iedereen IE gebruikt.

PS: je hebt het over "u1 en li" en ook in je eerdere Word-bijlage zag ik ergens de "u1" langskomen. Dat zit 'm waarschijnlijk in je viewer/editor/lettertype, waarbij de 1 (één) en de l (de kleine L) er hetzelfde uitzien.
De correcte schrijfwijze is: <ul > (<UL>, maar in XHTML moet je kleine letters gebruiken).

Het komt van Unordered List, een ongeordende lijst met stipjes. Daarnaast zijn er ook <ol>'s (<OL's) = Ordered Lists (genummerde lijstjes), en <li>'s (/LI>'s) List Items voor alletwee.
Dit even voor de lezers die dit toevallig nog niet wisten.

 

[pbd4499]

Hmm, ik kan me nu wel voorstellen waarom 'internet terug naar de tekentafel' moest.:thumb:

VB was al erg maar deze problemen slaan werkelijk alles!!!

Het gaat bij ons om Intranet en alle gebruikers draaien IE m.u.v. ict, deze lopen nogal uiteen wat betreft hun favoriete browser. Ik gebruik Firefox om snel met firebug te kunnen debuggen naar wat welk veld voor benaming, css etc heeft. Tis omdat IE dit niet heeft want anders gebruikte ik firefoxo ook niet.

Ik probeer de IE hack te gebruiken maar heb de juiste combinatie nog niet te pakken.

In het ergste geval open ik die pdf gewoon in een nieuw venster maar ik kies voorlopig nog ff voor perfectie en probeer het op te lossen met deze hack.

ja het moet uL zijn. Ik zie ze vaak voor een 1 aan als ik die tags ben aan het uitlezen. Dank je voor de waarschuwing.

 

[csshunter]

Hoi pbd4499,
Even recapituleren:

• Nodig is een makkelijk bladersysteem voor pdf's, een "Pdf-bibliotheek", zonder dat de pdf's apart geopend hoeven te worden, en er altijd een menu beschikbaar is.
• Methode: pagina met mooi uitklapmenu, eronder een iframe voor wisselende pdf-vertoning.
• Probleem: over de "control's" (bedienings-knoppenbalk) van de pdf in het iframe laat zich geen uitklapmenu uitrollen: dat komt onder het iframe terecht, waardoor het de submenu's onbereikbaar zijn.
• Bijkomende gegevens: Adobe zegt dat dat niet kan; in het Dreamweaver Spry-menu zit een IE-only script (niet crossbrowser dus); het gaat om een intranet-toepassing, waar hoofdzakelijk op Internet Explorer gedraaid wordt, maar soms ook op Firefox of andere browsers.

Nu geloof ik toch een eitje van Columbus uitgebroed te hebben!

We hebben ons driftig bezig gehouden met de vraag: "Hoe zorg ik ervoor dat een html-element zich tijdelijk vertoont in een laag boven een pdf in een iframe?".
Omdat een scherpe vraagstelling vaak de oplossing naderbij brengt, heb ik me in overleg met francky van developerscorner.nl nog eens opnieuw gebogen op de vraagformulering. Wat blijkt? Het is maar de halve vraag! Als je de vraag herformuleert tot:

• "Hoe zorg ik ervoor dat een html-element zich tijdelijk vertoont in een laag boven een pdf in een iframe?"
  òf:
  "Hoe zorg ik ervoor dat een pdf in een iframe tijdelijk verdwijnt (in een laag onder een html-element)?"

dan blijkt er toch iets in de buurt ...

... maar kijk eerst zelf !

Is dit iets wat in de richting komt?
Gebakken door francky. Gaat goed in IE7 en IE8, FF3 en FF3.5; window-size (& resolutie) bestendig, font-size bestendig, valid css, invalid html op 1 punt (maar voor een intranet niet essentieel).

Op de valreep: probleem opgelost, probleem erbij...
Is het testmodel op een oor na gevild, blijkt er toch een ernstige spaak in het wiel te zitten. Het hele concept van een iframe is in feite onbruikbaar...
Het blijkt namelijk (normaal doen we niet zo in frames, en lopen we er ook niet tegenop), dat links in een document in een iframe óók altijd in dat iframe geopend worden.

• Voor externe links is dat hoogst storend, maar het zou eventueel nog kunnen.
• Voor links in een pdf-je naar een ander pdf-je in de bibliotheek (de handige dingen voor de mensen; dan hoef je niet via het menu) is het echter onoverkomelijk: dan wordt binnen het iframe een nieuwe pagina met een tweede menu en nieuw iframe en al geopend:

Ai!
Gelukkig kon hier een mouw aan gepast worden door het <iframe> te vergeten en het <embed> element te gebruiken, dat weliswaar niet html-valid is, maar de links wel in een nieuw venster laat openen. Even alles omgooien en bijbehorende css uitvinden.
Op de testpagina's zitten daarvan nu ook een paar klik-voorbeeldjes.

Met vriendelijke groet,
CSShunter

Edit: nagekomen bericht:
Opera, Safari en Chrome hebben er ook geen moeite mee.
O ja, hij doet het desnoods ook zonder javascript.

 

[ErikBooy007]

Ik weet niet wat er bij anderen gebeurt, maar toen ik met m'n muis over het menu ging, crashte firefox direct. Ik kan je wel vertellen dat m'n laptop niets meer snel doet, maar dit ging razendsnel.

[EDIT]
Nog maar een paar keer geprobeerd om te kijken of het niet incidenteel was, en het is nu 4 keer achter elkaar gebeurd. Sorry
[/EDIT]

 

[Goeroeboeroe]

Geen petje af, maar 'n hoge hoed! Plus 'n koksmuts!
Ik heb niet de tijd om 't helemaal goed te volgen, maar ik heb wel 't resultaat even bekeken. Bij mij crasht 't niet in Firefox. 't Werkt goed (niet grondig getest) in Opera 9.64 en 10.0, Firefox 3.0.14 en 3.5, Internet Explorer 7 en 8, Google Chrome en Safari.
In Lynx zie je gewoon 't hele menu, en in Transformator ook (is 'n gratis 'reclame' voor 'n screenreader die draait op IE 7. Als 't daar in werkt, werkt 't in principe ook in die screenreader.)
In WebbIE, 'n browser voor blinden, zie je alleen 't menu bovenin, niet de submenu's. Maar die heeft wel meer bugs, dus...
'n Groter probleem is IE 6: daarin openen de submenu's niet. Ik neem aan dat dat 'n kwestie is van afwijkend JavaScript of zo en relatief makkelijk te verhelpen zou moeten zijn. Maar gezien mijn kennis van JavaScript is 't uitstekend mogelijk dat ik nu volledig aan 't raaskallen ben.
Wat betreft embed en 't niet valid zijn: soms wens ik de dames en heren van w3c heel even 'n acute galsteen of zoiets toe. Nadat ze 't jaren te vuur en te zwaard hebben bestreden, is 't in html 5 dus gewoon valid. Dus dat probleem lost zichzelf op. Je kunt ook nu al 't doctype van html 5 gebruiken, maar de specificatie verandert nog steeds, dus dat is wat listig.

 

[csshunter]

@ Erik: Zo probeer ik trage laptops achter de broek te zitten!

Maar niet dat ik er ook maar iets van begrijp: bij mij op/onder WinXP (op m'n vaste kast met FF3, en op een laptop met FF3.5) gaat alles van een leien dakje. En bij de andere browsers ook. - Ook de Javascript fout-console geeft keurig een groen lampje.

Het enige dat ik kan verzinnen (behalve systeem- of registerfoutjes): heb je misschien een andere website of een andere applicatie openstaan die er eventueel (zou niet mogen mogen) mee interfereert?
Als je in FF eerst de cache leegt en javascript uitzet, en het dan nog eens probeert, crasht ie dan ook?
O, en heb je de laatste versie van de Acrobat Reader erop? En welke FF-versie? En Windows, of iets anders?

Weinig antwoord, veel vragen!
En nog een vraag voor de andere lezers (als die nog durven): zijn er meer mensen bij wie Firefox spontaan op tilt slaat bij deze link? Zo ja, graag melden!

Met vriendelijke groet,
CSShunter

@ Goeroeboeroe: ik kom er aan!

 

[Goeroeboeroe]

@ Erik: en probeer 't ook 'ns met Firefox zonder extensies. Die willen soms ook nog wel 'ns 'n plug-in bijten of zo.

 

[csshunter]

Leuk dat je 'm zo nauwgezet hebt bezichtigd, en dank voor de complimenten, Goeroeboeroe! Er zaten best wel wat uurtjes trial and error onder de koksmuts. Terwijl toch op zich een heel simpele hotelschakelaar.

Omdat ik begrepen had dat het puur om een intranet ging en niet om een publieke site, had ik me eigenlijk helemaal niet om IE6 bekommerd, en mijn virtuele pc met IE6 erop rustig in z'n virtuele stofhoes laten staan.

• Als er op een intranet nog IE6-ers zitten, wordt het hoog tijd dat de afd. ICT eens een ronde doet om die oude knarren te vervangen: komt de veiligheid v/h intranet zeker ten goede!

Op goede toegankelijkheid had ik 'm om dezelfde reden ook niet echt getest. Maar goede html/css/js zou toch ... nietwaar? In elk geval: het uitklapmenu werkt niet 100% in scriptloze browsers (ook Fangs geeft alleen de hoofdmenu-items). Ik denk dat dat te ondervangen zou moeten zijn met omdraaien: de submenus standaard open zetten, en bij aanwezig javascript ze meteen onload weer uitzetten.
Dan onze vriend IE6. Die zou het in principe moeten doen, want het menu is afkomstig van deze Liquidfish testpagina - en die doet het ook in IE6 (net als de originele Suckerfish; iets hogers was er toen nog niet).
Dus toch even de virtualiteit in. Aha, het verschil met de Liquidfish is dat daar het script in de pagina zelf zat, en hier separaat is. Het lijkt als of IE6 gewoon het script niet ziet (maar de link is wel goed, dus). Het js-bestand gedownload en bekeken: blijken in Notepad vreemde tekens in te staan bij tabs en harde returns. Oe! Dat hoort niet. Een rechtlijnig txt-bestand zal het waarschijnlijk oplossen. Nog es proberen als ik tijd heb.
Want een toegankelijk universeel model is toch het mooist!

Zeer gegroet,
(en morgen weer vroeg op ...)
CSShunter

 

[pbd4499]

Heren, het probleem van de laptop zal wel een virus zijn want hier sloegen de stoppen van de virusscanners door...:evil:

 

[ErikBooy007]

Als ik JS uitschakel crashed FF niet. Maar dan heb je een grote lege ruimte zoals ook wordt aangegeven

Ik vind het vreemd. Alle add-ons uitzetten werkte ook niet. Ik krijg ook géén foutmelding of reden van de crash of iets dergelijks.

Verder werk ik met FF 3.5.3 onder Windows Vista.

 

[Goeroeboeroe]

Ah, het ging om 'n intranet. Had ik niet gezien. Als iemand 't dan elders wil gebruiken, blijft er nog wat te doen over.
Ik heb persoonlijk 't idee dat 't toch al redelijk toegankelijk is. WebbIE is voor mij 'n extra, ik vind die niet echt geweldig. Heb er nog 'ns naar gekeken, en 't blijkt de bedoeling te zijn dat je die combineert met 'n screenreader. Oeps.
Transformator werkt wel goed, en die komt van de maker van 'n screenreader (weet de naam niet uit m'n hoofd). En Lynx laat 't ook goed zien, terwijl die volgens mij ook niet goed uit de voeten kan met JavaScript.

@Erik: bij mij is het Firefox 3.5.3 onder XP (en 3.0.en.nog.wat onder Linux). Zou het aan het verschil tussen Vista en XP kunnen liggen? Zijn er nog anderen die Firefox 3.5 kunnen proberen op Vista en XP?

 

[csshunter]

@Erik
Ik heb nu het suckerfish-scriptje in een pagina zelf gehangen.
Crasht ie hier ook op? bieb-home-inlinescript.htm

Zo nee, dan zal het de encodering zijn waarmee sf.js is opgeslagen (zie mailtje aan Goeroeboeroe hierboven).
Zo ja, dan gaan we verder elimineren
.
Versie zonder het hele sf-script (is toch maar voor IE): bieb-home-nosuck.htm

If hierop geen crash > toch iets in het sf-script, hoewel dat begint met if(document.all){...}.
If wel crash:
... dan zou er iets in de functie showWachtframe() moeten zitten, want dat is verder het enige script, in werking bij hoveren over het menu.

Maar die functie is eenvoudigweg:
[JS]function showWachtframe(){
var embedstyle = document.getElementById('pdfembed').style;
var statusIs = document.getElementById('statusIs').style;
var waitstyle = document.getElementById('framework').style;
var statusWas = document.getElementById('statusWas').style;

embedstyle.display = "none"; // embed met pdf uitzetten
statusIs.display = "none"; // "U bent hier:" in breadcrumbs uitzetten

waitstyle.display = "block"; // en wachtscherm aanzetten
statusWas.display = "inline-block"; // en "U was hier" aanzetten
}[/JS]
Vreemd hoor!

@ Pbd4499

sloegen de stoppen van de virusscanners door..

Bij entree in mijn pdf-bieb? Wat een eer!
En nog wel virusscanners (meervoud)!
Dewelke?
En vertelde(n) de virusscanner(s) erbij welk bestand gevireerd was? Het html-bestand(UTF-8), het suckerfish.js (Kladblok-werk), het css-bestand (ook Kladblok), een pdf-je (gemaakt met OpenOffice), de plaatjes (home made met PaintShopPro)?
... o, het enige "vreemde" element is BY-NC-SA.png, die heb ik niet zelf gemaakt maar gedownload van CreativeCommons. Zou me verbazen als dat 'm was!
Of zegt de virusscanner dat gewoon de hele site niet deugt, of zoiets?
Vreemd hoor!
- Wat gebeurt er als je de diagnose-route van hierboven volgt?

Met vriendelijke groet,
CSShunter

 

[That Guy]

Zijn er nog anderen die Firefox 3.5 kunnen proberen op Vista en XP?

De pagina doet het hier prima in firefox 3.5.3 op XP en Vista; mischien heeft het toch met de laptop van Erik te maken...

 

[csshunter]

En @Goeroeboeroe
Hmm, was niet helemaal (helemaal niet) correct wat ik eerder zei over de rol van javascript ivm toegankelijkheid. De submenus staan er gewoon in, ook als het js uit staat. Kan je in Firefox zo zien via Beeld > Geen Stijl.

Wat aan de hand zal zijn (en waar wel voor gewaarschuwd wordt op accessibility-sites), is dat sommige niet-visuele browsers nogal rigoreus omgaan met { display: none: }: dan slaan ze dat element helemaal over, óók als de styles uitgeschakeld staan.

Normaal gesproken maak ik daarom mijn class="invis" aan met { position absolute; margin-left: -9999px; }, de buiten-beeld-methode die binnen-beeld wordt gehaald met het script. Die wordt wel altijd gezien, en dan komt Fangs ook aan zijn trekken.

In het Suckerfish-voorbeeld hadden ze dat niet toegepast, dus.
Maar even snel gekeken wat als margin-left:-9999px. Ja hoor, ook Fangs ziet de submenu's weer.

Met vriendelijke groet,
CSShunter

 

[ErikBooy007]

Ik heb het ook nog even op je nieuwe link geprobeerd en daar crashet (??) ie evengoed. Overigens wel pas als ik over je links hover. Hij geeft het submenu dan wel weer, maar als ik dan de cursor beweeg, floept firefox gewoon weg. Dat is bij beide links hetzelfde.

Maar ik denk dat het dan inderdaad aan m'n laptopje ligt. Gelukkig komt er snel een andere

 

[ErikBooy007]

Ik heb hier trouwens ook nog een PC-tje staan waar nu even Linux op staat. Daar doet ie het (uiteraard) wel prima! :thumb:

 

[csshunter]

Ha, zucht!

 

[pbd4499]

A)

Bij entree in mijn pdf-bieb? Wat een eer! 
B) En nog wel virusscanners (meervoud)! 
C) Dewelke?
D) En vertelde(n) de virusscanner(s) erbij welk bestand gevireerd was? Het html-bestand(UTF-8), het suckerfish.js (Kladblok-werk), het css-bestand (ook Kladblok), een pdf-je (gemaakt met OpenOffice), de plaatjes (home made met PaintShopPro)?
E)... o, het enige "vreemde" element is BY-NC-SA.png, die heb ik niet zelf gemaakt maar gedownload van CreativeCommons. Zou me verbazen als dat 'm was!
F)Of zegt de virusscanner dat gewoon de hele site niet deugt, of zoiets?

A) weet niet of het jouw pdf-bieb was. Heb slechts gemeld dat ik bij het klikken van een der links de waarschuwing kreeg.
B) lokale scanner & netwerkscanner (AC)
C) maar heb de virusnaam niet genoteerd.
D) er werd een (A.EXE) gedownload => temp internet files
E) geen idee
F) het is me onduidelijk van welke site met welke links zijn gekoppeld, heb ik niet meer nagekeken en ben gaan schoonmaken:evil:


doet de functie : showWachtframe het met de knoppen bovenop de embedded pdf? heb hem nog niet getest.

 

[csshunter]

Hoi pbd4499,

... er werd een (A.EXE) gedownload => temp internet files

De eerste Google-hit vertelt: "a.exe is registered as the W32.Ahlem.A@mm worm which is transmitted via e-mail and attempts to install itself on your computer." Andere Google-resultaten hebben het over een virus, en weer andere hebben het over de Alcra-worm die de a.exe wil implanteren.
Een lastige jongen, als je bv. dit leest: "Probeert verschillende programma's uit te schakelen." ...
Ik heb dus meteen al mijn harde schijven en partities doorzocht, maar hier gelukkig niets aangetroffen (anders zouden mijn Norman en/of SpywareTerminator ook wel eerder gewaarschuwd hebben vermoed ik).
Anyway, in mijn javascripts in de pdf-bieb-bladzijden heb ik geen stiekeme downloads ingebakken. En de links in de pdf-bieb-bladzijden gaan òf naar elkaar, òf naar niks (href="#"); met als uitzondering de link "http://creativecommons.org/licenses/by-nc-sa/3.0/nl/" (maar die zie ik er ook niet voor aan om potjes wormen te verspreiden).

Al met al denk ik dat het een toevallige samenloop van omstandigheden is geweest, waardoor het virusalert bij jou opsprong toen je een link naar de pdf-bieb aanklikte. Of helpmij.nl zou er wel een hele slimme truc voor moeten hebben (in de statusbalk is alleen de link te zien) om tijdens het openen van de link naar de pdf-bieb tegelijkertijd een download te starten.
Een grote schoonmaak lijkt me in elk geval geen kwaad kunnen.

Maar uit je vervolgvraag maak ik op dat het je ook zonder crash gelukt is om de pagina's te zien:

doet de functie: showWachtframe het met de knoppen bovenop de embedded pdf? heb hem nog niet getest.

Eh, ja, anders had ik hem niet durven insturen.
En Goeroeboeroe zei ook van wel, die durf ik niet tegen te spreken.

Tenslotte mijn hamvraag: ben ook benieuwd hoe het resultaat van de knutselarij je eigenlijk bekomen is, want dat heb ik nog niet gehoord: was zoiets de bedoeling?

Met vriendelijke groet,
CSShunter