Jeg har en maskine med dansk Win7-Pro, og den bruger samme datoformat. Den konvertering er helt lige til:
<script type="text/vbscript"> Function Foo() Dim fso, f, sDate
Set fso = CreateObject("Scripting.fileSystemObject") Set f = fso.getFile("__MenuTest.html") sDate = f.DateLastModified Set f = Nothing Set fso = Nothing Foo = sDate End Function </script>
<script type="text/javascript"> var oDate = new Date(Foo()); alert(oDate) </script>
PS: Når du tester den slags ting, så udnyt, at Explorer forstår både VBS og J(ava)Script. Ydermere kan du sende simple datatyper som String, Number og Boolean frem og tilbage mellem de to sprog - men glem de komplekse som Array og Object =)
Så har man selvfølgelig sikkerhedsadvarsler at slås med, når man prøver at instantiere et AX-object i Explorer. Det kan du dog undgå ved at kalde filen *.hta - i stedet for *.html
En HTA (HyperText Application) er en wrapped instans af IE, som ligner et alm. Windows program - og som har andre sikkerhedsindstillinger.
Hele HTA referencen (den er såmænd ikke så stor) ligger her - men det hurtige cowboy-hack til test er bare at kalde filen *.hta =)
Ja, HTA WSF er sjovt at lege med. Jeg foretrækker jscript, og har endnu ikke fundet ting jeg ikke kunne gøre i jscript (jo, msgbox), men så laver man jo netop bare en vbscript funciton til det man skal bruge.. super sejt at man bare kan krydsreferere på den måde
Nu hvor jeg har dig.. kender du til en metode hvorpå man kan dragdroppe filer på HTA app'en sådan at de bliver registeret i HTA'en?`
Hra prøvet forskellige hacks, der inkluderede iframes, og registry settings.. men intet har virket.
--
Man burde bare lære sig et "ordentligt" kode sprog.. =P
Jej bruger skam også (næsten udelukkende) selv JScript i HTA'er. Det er en hurtig måde at lave en pæn UI til alle mulige scripts =)
Hvis du mener drag/drop af filer, så er svaret: Won't work :o|
I en modal (eller modeless) dialog kan du godt få MS' drag/drop events til at fyre - men du kan ikke få fat i filnavn/-sti. Så skal du have fat i .net framework'et eller det gamle VB (VB 5 eller 6).
Jeg lavede til gengæld på et tidspunkt en quick'n'dirty Windows Gadget, som validerer en HTML- eller CSS-fil hos W3C - en rund knap på størrelse med gadget uret.
Jeg kan trække filer over på den, og så bliver resultatet vist i en HTA. Den detekterer selv, om det er en CSS- eller HTML-fil og validerer på det tilsvarende site. Jeg kan også trække en adresse fra Explorer's adressefelt over på den, hvorved det er den pågældende side, der HTML-valideres.
Det kan lade sig gøre, fordi gadgets stiller visse features til rådighed, som ikke er til rådighed i en HTA - og som du ikke kan hacke dig til ... herunder metoden System.Shell.itemFromFileDrop =)
Hvad MsgBox angår, så bruger jeg selv følgende kode (ligger i et privat framework, som jeg fast inkluderer):
<script type="text/jscript"> // -- Namespace for 'constants' var C = {};
Har du i øvrigt lagt mærke til den lidt irriterende ting, at med IE9 er HTA'er begyndt at vise hele stien i caption baren - i stedet for bare filnavnet?
Et lille hack, hvis du gerne vil bevare 'App' looket: Brug denne meta:
- hvorefter du er kørende med alle IE9's features. Lidt bøvlet, men absolut en mulighed =)
Et andet problem er kommunikation mellem flere HTA'er. Du kan åbne en HTA fra en HTA med [b]Shell.run, og du kan medsende parametre. Dem kan du hente ud med [HTA-ID].commandLine og parse strengen - men så er den heller ikke længere.
Den nyåbnede kan ikke finde sin parent - eller omvendt. Det skyldes bl.a, at HTA'en er en IE-instans, som er wrapped i programmet mshta.exe. En alm. webside kan kommunikere med en popup, fordi der er tale om to instanser under samme 'programskal'.
Jeg lavede dog engang et hack. Jeg åbnede en skjult instans af Explorer med new ActiveXObject("InternetExplorer.Application") og gav instansens window object et 'unikt' genereret navn. Derudover satte jeg en variabel opener=window; med en reference til HTA'en selv.
Så åbnede jeg en ny HTA med Shell og sendte det 'unikke' navn med som parameter. Denne HTA kikkede så Shell.Windows igennem, til den fandt et vindue med dette navn. Så vidste jeg, at [DETTE-VINDUE].opener refererede til den første HTA's window object.
Så var det bare at lade 'ET phone home' - lægge en reference i en variabel i den første HTA og lukke den skjulte IE-proxy.
Omstændigt, ja! Men det lod sig gøre, og jeg er absolut også til hacks *D
Det jeg er mest tilfreds med at have "hacket" er en custom caption bar (så borderless, med custom "menubar") - så man slipper for windows default bar knapper border osv.
--
Jeg er så ærgelig over at jeg først har lært til HTA for nygeligt.. det kan jo det meste!.. og med 3dje parts commandline tools..så kommer man virkeligt langt.
Nej, der findes mig bekendt ikke en debugger specielt for HTA.
Jeg kender godt HUI, men udvikleren bag har hverken særlig godt styr på COM eller webkode - hvilket hans kode bærer præg af - så jeg bruger det ikke.
Jeg har selv skrevet et library. Det består af et object, der fungerer som namespace. På det ligger en bunke statiske helper funktioner samt de vigtigste widgets i form af menubar, knapbar, tree- og listview, etc.
Et meget sjovt projekt, som jeg for sjov roder lidt med engang imellem, er en HTA, hvori jeg kan 'bygge' HTA-applikationer. Det er ikke færdigt, men bliver det færdigt, kan det være, jeg smider det op til download =)
Jeg har også gang i mit eget..og er nået et godt stykke.. men der er så meget der kan laves.
Er ligenu igang med at lave filsøgnings mekanisme hvor man kan definere størrelse, dato, extension, filenavn-indeholder/ikke..osv. Det skal ske async sådan at HTA'en kan processe funder filer med det samme.
hele async delen virker fint..manglede bare lige filter--funktionerne - defor jeg skulle bruge info omkring dato =)
Nej, jeg har ikke noget at bruge CS-Script til, så det er udelukkende skrevet med henblik på mshta. Med C# i .net har man native adgang til de fleste af HUI's features - og ellers bruger jeg ikke CS =)
Det kommer an på, hvad du mener med 'ikke fungere' =)
Denn kode fungerer jo sådan set udmærket:
var oHttp = new ActiveXObject("WinHttp.WinHttpRequest.5.1"); oHttp.open("get", "http://www.eksperten.dk", false); oHttp.send(); alert(oHttp.responseBody());
- men p.gr.a. de evindelige tegnsætproblemer giver den et lidt 'pudsigt' resultat, som ikke umiddelbart er anvendeligt.
Er du slet ikke stødt på problemer med utf-8 filer? Hvis du f.eks. skriver settings- eller INI-filer, er det jo oplagt at skrive dem som JSON-filer - og da vi taler/skriver dansk og gerne vil kommunikere med resten af verden, er utf-8 oplagt at bruge.
Problemet er bare, at det vil FileSystemObject ikke være med til. Når du så har fået løst det med ADODB-streams, løber du ind i problemer med BOM-tegn, som JS' JSON.parse ikke kan håndtere.
Man kommer ikke til at kede sig, når man forsøger at blande MS' klassiske AX-objekter, JS og moderne kommunikationsteknologi *o)
Men jeg forstår i øvrigt ikke, at gerne vil holde dig fra det tegnsæt, langt den største del af den vestlige verden som default bruger på WWW - utf-8.
Hvis du påtænker at 'tale med' WWW, er det nok ikke smart at basere sin kode på, at alt skal tolkes/konverteres. Så er det nok smartest at bruge det tegnsæt, 'de andre' bruger =)
Hvis du prøver alert(typeof oHttp.ResponseBody), får du returneret 'Unknown'. Det skyldes, der ikke er tale om en streng - og derfor kan du ikke behandle den som sådan =)
"troede bare det var "unknown" af den simple årsag at jscript bare ikke kunne håndtere datatypen" >> Jamen, det er præcis årsagen. JS kan ikke håndtere binære data =)
#31: Det betyder alt! Dine filer skal naturligvis være gemt med den encoding, der svarer til encoding af de data, filerne skal behandle. Det giver ikke mening at bruge Unicode i ANSI-filer.
Når du skriver 'Unicode', hvad er det så, du præcist mener? Little eller Big Indian ... eller?
Ok..normalt plejer jeg ikke at unkludere strenge der indeholder special tegn i mine script filer.. alt sådan noget bliver loadet eksternt.
Kan godt se at hvis man partout skal inkludere special tegn i selve scriptet.. så bliver man nødt til at bruge encoding (klart nok).. men at _skrive_ unicode.. det ser jeg umiddlebart ikke som et problem.
Jaja, al det pjat med at bruge dollar i snesevis af millioner på at udvikle og vedligeholde standarder for data encoding - samt tage hensyn til disse under softwareudvikling - skyldes naturligvis, at folk ikke har fattet en fis *o)
Du kan ofte køre i timevis i venstre side af motorvejen og overleve - men man sætter vand over til seriøse problemer!
Du er nødt til at sætte dig grundigt ind i, hvad datatyper og encoding er for noget, når du vil lege på den bane. I webteknologi gælder samme regler, men der bliver vi tørret bag i af servere og klienter, som tager sig af langt de fleste problemer.
Men også der har folk masser af problemer med tegnsætskonflikter. Det vidner Ekspertens kategorier for serversprog tydeligt om *o)
Hvis din tilgang fra begyndelsen havde været f.eks. Java, C++ eller C#, ville dine overvejelser have set helt anderledes ud =)
ja, jeg er en glad amatør. Jeg gør mine overvejelser efterhånden som jeg støder ind i problemer =)
Men altså ..lige omkring at skrive special tegn har jeg bare ikke haft de store problemer.. (når vi snakker webserver, database og visning i browseren..ja så ved jeg godt hvad du mener.)
Men lige hér i wsh har jeg ikke de vilde problemer..
Det eneste er, jeg har måtte bygge min egen html decoder for at kunne parse html entiteter, og de forskellige formateringer som unescape() ikke kan klare - Synes ikke rigtigt jeg kunne finde noget på det.
HTML-entities bruger man jo ikke rigtig mere på WWW - nu, hvor de facto standarden hedder utf-8. JS' escape og unescape har været deprecated i årevis og er erstattet af Unicode metoder.
Jeg er ret sikker på, at det, du kalder "normal" tekst, er noget andet end det, jeg kalder normal tekst. Jeg er helt klar over, at man må tage højde for alle mulige klaphatte 'derude' - men vi er fundamentalt uenige om, hvordan det bør gøres =)
Lige en hurtig.. jeg vil gerne sætte zoom faktor for IE explorer i registry. Det er et DWORD, _Skal_ værdien sættes med hexadecimal og i så fald, er det så som string?
var wsh = new ActiveXObject("WScript.Shell"); wsh.RegWrite ("HKCU\\Software\\Microsoft\\Internet Explorer\\Zoom\\ZoomFactor", "186a0", "REG_DWORD");
var wsh = new ActiveXObject("WScript.Shell"); wsh.RegWrite ("HKCU\\Software\\Microsoft\\Internet Explorer\\Zoom\\ZoomFactor", 0x000186a0, "REG_DWORD");
"Så ville bare sætte browser zoom til 100%, og sætte den tilbage til "original" når scriptet var færdigt"
Bliver det mon særlig brugervenligt? IE skal jo i hvertfald lukkes ned og åbnes igen for at ændringen kan have indvirkning på noget. Tror du ikke, det bliver for bøvlet?
I øvrigt mener jeg ikke, det kan skyldes zoom, hvis noget ser forkert ud. Det er som udvikler din opgave at tage hensyn til brugeren - og at hun meget vel kan være svagtseende. Et brugbart design tager højde for den slags brugerindstillinger.
Hvis noget ser forkert ud ved zoom forskellig fra 100%, skyldes det ikke zoom værdien, men et skidt udført design =)
Til konventionelt webdesign gir jeg dig tildels ret.
Men her prøver jeg at efterligne et win2k stylet vindue, og f.eks border til at lave den der klassiske "outset" effekt, så f.eks min border på vinduet skal altid fremstå som 1px..
Anyways, du må se resultatet nå det er færdigt..så kan du selv bedømme =)
At Microsoft gør sig skyld i den komplet tåbelige antagelse, at svagtseende kun er svagtseende, når de anvender en browser, udgør næppe et eksempel til fornuftig kopiering. Hvorfor ikke rette de værste og mest åbenlyse fejl, Microsoft begår?
Og så forstår jeg nok heller ikke helt, hvorfor du stræber efter at efterligne antikke OS'er.
Ja, præcis.. har været i gang med at svare et par gange =)
Jeg vil sige i store træk "ja" , men om du kan tage dit "XYZ-projekt" baseret på Servcerside VBScript og så bare køre det igennem en HTA og så forvente at alt virker.. nej, det tror jeg ikke =) - men igen, det er ikke umuligt, kommer an på så meget.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.