---

Nå så er den gal igen

Følgende er en lille snut fra mit installations program.

I snutten kopieres alle filer fra app.path\dwg til destination folder
defineret i Text1 -
Og det fungerer da sådan ca. også godt nok

.... men følgende linie kan jeg ikke få til at fungere !

LabStatus = "Now Copying AutoCAD Drawing" & " " & File1

Der bliver først skrevet i lablen LabStatus når filerne er kopieret, og så
er fidusen ligesom forsvundet

LabStatus skal fungere som en simpel "statusbar" ... jeg ønsker ikke at
tilknytte componenter til formen !

Er der nogen der har et bud på hvorfor LabStatus ikke løbende bliver
"opdateret" ?

Med Venlig hilsen Neo




'Her kopieres alle filer i \dwg

If Right(App.Path, length:=1) = "\" Then
File1.Path = App.Path & "dwg"
Else
File1.Path = App.Path & "\dwg"
End If

Dim SourceFile, DestinationFile
Dim Count
Dim NumFiles As Integer

NumFiles = File1.ListCount - 1 'antal filer i det givne bibliotek
For Count = 0 To NumFiles

File1.ListIndex = Count 'navn
LabStatus = "Now Copying AutoCAD Drawing" & " " & File1

SourceFile = File1.Path & "\" & File1 ' Define source file name.
DestinationFile = Text1 & "\dwg\" & File1 ' Define target file name.

FileCopy SourceFile, DestinationFile ' Copy source to target.
Next Count

---

On Fri, 11 Oct 2002 11:07:24 +0200, "Neo.dk"
<neo___dk@hotmail.removethis.com> wrote:

>Nå så er den gal igen
>
>Følgende er en lille snut fra mit installations program.
>
>I snutten kopieres alle filer fra app.path\dwg til destination folder
>defineret i Text1 -
>Og det fungerer da sådan ca. også godt nok
>
>... men følgende linie kan jeg ikke få til at fungere !
>
> LabStatus = "Now Copying AutoCAD Drawing" & " " & File1
>
>Der bliver først skrevet i lablen LabStatus når filerne er kopieret, og så
>er fidusen ligesom forsvundet
>
>LabStatus skal fungere som en simpel "statusbar" ... jeg ønsker ikke at
>tilknytte componenter til formen !
>
>Er der nogen der har et bud på hvorfor LabStatus ikke løbende bliver
>"opdateret" ?

LabStatus = "Now Copying AutoCAD Drawing" & " " & File1
LabStatus.Refresh

Maybe.......

--
Snutten
Reply-to adressen er gyldig inntil spam er mottatt

---

"Neo.dk" <neo___dk@hotmail.removethis.com> skrev i en meddelelse
news:3da69450$0$79645$edfadb0f@dspool01.news.tele.dk...
> Nå så er den gal igen
>
> Følgende er en lille snut fra mit installations program.
>
> I snutten kopieres alle filer fra app.path\dwg til destination folder
> defineret i Text1 -
> Og det fungerer da sådan ca. også godt nok
>
> ... men følgende linie kan jeg ikke få til at fungere !
>
> LabStatus = "Now Copying AutoCAD Drawing" & " " & File1
>
> Der bliver først skrevet i lablen LabStatus når filerne er kopieret, og så
> er fidusen ligesom forsvundet
>
> LabStatus skal fungere som en simpel "statusbar" ... jeg ønsker ikke at
> tilknytte componenter til formen !
>
> Er der nogen der har et bud på hvorfor LabStatus ikke løbende bliver
> "opdateret" ?
>
> Med Venlig hilsen Neo
>
>
>
>
> 'Her kopieres alle filer i \dwg
>
> If Right(App.Path, length:=1) = "\" Then
> File1.Path = App.Path & "dwg"
> Else
> File1.Path = App.Path & "\dwg"
> End If
>
> Dim SourceFile, DestinationFile
> Dim Count
> Dim NumFiles As Integer
>
> NumFiles = File1.ListCount - 1 'antal filer i det givne bibliotek
> For Count = 0 To NumFiles
>
> File1.ListIndex = Count 'navn
> LabStatus = "Now Copying AutoCAD Drawing" & " " & File1
>
> SourceFile = File1.Path & "\" & File1 ' Define source file name.
> DestinationFile = Text1 & "\dwg\" & File1 ' Define target file name.
>
> FileCopy SourceFile, DestinationFile ' Copy source to target.
> Next Count
>
Prøv at sætte en DoEvents efter LabStatus = ....

Jan

---

Jan V. skrev:
> Prøv at sætte en DoEvents efter LabStatus = ....

Av - av - av. Pas på med de "DoEvents".

Det vil godt nok løse Neo's problemer lige nu, men kan lige så let
skabe nye, hvis han ikke har HELT styr på hvad DoEvents gør eller kan
gøre!

-------
Tomas

---

"Tomas Christiansen" <toc-nospam-01@blikroer.dk> skrev i en meddelelse
news:ao7fvs$3h9$1@news.cybercity.dk...
> Jan V. skrev:
> > Prøv at sætte en DoEvents efter LabStatus = ....
>
> Av - av - av. Pas på med de "DoEvents".
>
> Det vil godt nok løse Neo's problemer lige nu, men kan lige så let
> skabe nye, hvis han ikke har HELT styr på hvad DoEvents gør eller kan
> gøre!
>
> -------
> Tomas
>
Jeps

Man kan hurtig gøre en effektiv procedure MEGET langsom, hvis man sætter
DoEvents hver gang den løbes igennem.

Men det var nu opdateringen jeg tænkte på - den kommer ikke uden DoEvents.

Jan

---

Er der en venlig sjæl, der kan uddybe farerne ved DoEvents lidt?

Jeg naive sjæl har opfattet DoEvents sådan, at den 'frigiver' Windows til at
gøre evt. andre processer færdige, inden den går videre.
Derfor bruger jeg typisk kommandoen, hver gang jeg sender en Sql over i
Access - for at sikre, at Access-motoren bliver færdig, inden VB drøner
vider.

Men det er måske _helt_ ude i hampen?

mvh

Krabsen


>
> "Tomas Christiansen" <toc-nospam-01@blikroer.dk> skrev i en meddelelse
> news:ao7fvs$3h9$1@news.cybercity.dk...
> > Jan V. skrev:
> > > Prøv at sætte en DoEvents efter LabStatus = ....
> >
> > Av - av - av. Pas på med de "DoEvents".
> >
> > Det vil godt nok løse Neo's problemer lige nu, men kan lige så let
> > skabe nye, hvis han ikke har HELT styr på hvad DoEvents gør eller kan
> > gøre!
> >
> > -------
> > Tomas
> >
> Jeps
>
> Man kan hurtig gøre en effektiv procedure MEGET langsom, hvis man sætter
> DoEvents hver gang den løbes igennem.
>
> Men det var nu opdateringen jeg tænkte på - den kommer ikke uden
DoEvents.
>
> Jan
>

---

Krabsen skrev:
> Er der en venlig sjæl, der kan uddybe farerne ved DoEvents lidt?

Naturligvis.

> Jeg naive sjæl har opfattet DoEvents sådan, at den 'frigiver'
Windows til at
> gøre evt. andre processer færdige, inden den går videre.

Nej, det er ikke Windows der er problemet (Windows ER et problem, men
ikke i denne sammenhæng), det er den måde VB serialiserer (afvikler)
tingene på.

VB har en slags besked (~opgave) kø, hvor den modtager beskeder om
hvad der skal gøres. Der kan kun udføres én ting ad gangen. Denne
begrænsning ligger i VB og ikke i Windows, som sagtens kan køre flere
ting på samme tid. Begrænsningen sikrer at den samme stump VB-kode
ikke bliver kaldt igen og igen inden den når at afvikle færdig. Det
sikrer også at der aldrig bliver afviklet noget VB-kode "midt i" at
noget andet kode er under afvikling (med de undtagelser som altid skal
til for at bekræfte reglen...)

Når du skriver noget kode i f.eks. Command1_Click event-proceduren,
kan du altså være sikker på at Command2_Click ikke lige pludselig
bliver udført før Command1_Click er færdig afviklet. Brugerens klik på
Command2 (eller andre kontroller) bliver lagt i besked-køen, og bliver
først taget i betragning, når der ikke er andet at lave. Det samme
gælder f.eks. for Timer-events, hvilket resulterer i at Timer-events
kan "forsvinde" ud i det blå, hvis der når at komme et nyt
Timer-event, inden Timer-event proceduren er færdigafviklet (der
"huskes" nogle få events af samme type - præcis hvor mange ved jeg
ikke).

Hvis du opdaterer det synlige indhold af en kontrol på din form,
f.eks. Label1.Caption = "Noget nyt", lægges en besked om at dens
synlige del på skærmen skal opdateres. Denne besked bliver, ligesom
det gælder for alle andre beskeder, først behandlet, når VB ikke har
mere kode at udføre. En uendelig løkke i dit program resulterer altså
i at programmet, set fra brugerens synspunkt, er "låst" - det reagerer
ikke på tastetryk eller museklik og formen og dens indhold bliver ikke
opdateret på skærmen.

Heldigvis har de fleste kontroller en Refresh metode, som øjeblikkelig
opdaterer den synlige del af den pågældende kontrol (eller alle
kontroller på formen hvis det er formens Refresh som kaldes).

Hvad er så lige at DoEvents gør?

Jo, DoEvents suspenderer afviklingen af den aktuelle VB-kode og
behandler det, som måtte ligge i besked-køen. Først når besked-køen er
færdigbehandlet (det er vist ikke klart defineret om ALT bliver udført
eller "det meste" eller "en del", men generelt skal man regne med at
ALT i besked-køen bliver udført), genoptages afviklingen af den
suspenderede kode.

Hvordan kan det være så farligt?

Der er ganske mange ting, som kan gå galt. Hvis f.eks. at din
Command1_Click ser således ud:

Private Sub Command1_Click()
m_lCount = m_lCount + 1 'Global variabel
DoEvents
MsgBox "Dette er " & m_lCount & ". gang"
End Sub

Hvis man klikker hurtigt flere gange efter hinanden på Command1, vil
man kunne risikere at programmet fortæller at:

Nu er det 5. gang
Nu er det 5. gang
Nu er det 5. gang
Nu er det 5. gang
Nu er det 5. gang

Hvorfor nu det?

Jo: Et klik behandles. Den globale variabel bliver talt én op.
Afviklingen bliver suspenderet. Et nyt klik behandles. Den globale
variabel bliver talt én op. Afviklingen bliver suspenderet. Et klik
behandles. Den globale variabel bliver talt én op. Afviklingen bliver
suspenderet... osv.

Det kan altså være forbundet med en alvorlig risiko at ændre på
_nogetsomhelst_ globalt (det være sig variabler, indhold af
kontroller, andre objekter, database, ...) hvis man bruger DoEvents,
og IKKE har sikret sig, at ens kode ikke bliver kaldt igen.

Et andet eksempel kan være at brugeren har tre knapper: En
backup-knap, en slet-knap og en restore-knap.
Det handler om indholdet af et bibliotek, som der kan tages en kopi af
(backup), filerne kan blive slettet eller filerne kan genskabes fra
kopien.

Backup-rutinen ser således ud:

Sub Backup()
For Each File In Directory
Label1 = "Tager kopi af filen " & File.Name
DoEvents
MakeBackup File
Next
End Sub

Slet-rutinen ser sålede ud:

Sub Slet()
Label1 = "Sletter alle filerne"
For Each File In Directory
SletFil File
Next
End Sub

Hvis brugeren trykker på Backup-knappen, og _inden_ kopieringen af
filerne er færdig, kommer til at trykke på Slet-knappen, vil alle
filerne blive slettet midt i det hele, og backup'en er ikke komplet.

Hvis DoEvents i stedet var erstatte af Label1.Refresh, ville der ingen
skade ske, idet procduren Slet ikke ville bliver udført før procedure
Backup var helt færdig.

Håber at det gav en vis forståelse for hvad DoEvents gør, og hvorfor
den kan være så farlig.
Naturligvis kan man i de viste eksempler let sikre sig mod at der kan
klikkes på knapperne flere gange, idet de blot disables ved starten af
en klik-event-rutine og enables igen ved slutningen af en
klik-event-rutine (hvilket man iøvrigt altid bør gøre), men det kræver
at man ved hvad der kræves, og hvis f.eks. DoEvents ligger skjult i en
ekstern ActiveX-DLL, kan det være svært at gennemskue problemerne!

-------
Tomas

---

Tomas Christiansen skrev:
> Nej, det er ikke Windows der er problemet (Windows ER et problem, men
> ikke i denne sammenhæng), det er den måde VB serialiserer (afvikler)
> tingene på.

Jeg var vist lidt upræcis på netop dette punkt.

De ældre Windows-versioner, benyttede sig af en form for kooperativ multiprocessering (multitaskting) eller frivillig processkift,
hvor hver enkeltproces, selv skulle afgøre hvornår det var tid til at "slippe" CPU'en for en stund, så de andre programmer kunne
komme til. Dette kunne man så sikre sig ske, ved at indsætte DoEvents passende steder i sin kode.

I nyere versioner af Windows, benyttes ikke længere frivillig processkift, men derimod _tvungen_ processkift (preemptive
multitasking - ja, kært barn har _mange_ navne), som sikrer at alle "kommer til mølle" og at ingen bliver "udsultet".

Grundet Microsofts åbenbart helt utrolig dårlige implementation af preemptive multitasking - selv i Windows 2000 - kan man dog
stadig observere programmer, kørende med "normal" prioritet, tage alle ressourcer fra stort set alle andre programmer, så computeren
i lange perioder "låser" helt op. Dette burde naturligvis ikke kunne lade sig gøre, hvis man havde skelet blot en lille bitte smule
til mainframe-verdenen, hvor den slags ikke har været den store kunst i 25 år - suk, Microsoft...

Dem som har prøvet at køre med Windows NT, Windows 2000 (og formentlig Windows XP) på en computer med 2 CPU'er, vil kunne tale med
om at spørgsmålet om 1 eller 2 CPU'er _virkelig_ gør en forskel (systemet kører som en "drøm"!). Her vil en CPU-krævende proces kun
"tage" den ene CPU, og den anden CPU er klar til at tage sig af de øvrige opgaver. På et system, som er bedre til at fordele
ressourcerne, vil denne forskel være mindre markant.

-------
Tomas

---

Jamen det var da en herligt forståelig forklaring

Takker mange gange

mvh
Krabsen



"Tomas Christiansen" <toc-nospam-01@blikroer.dk> skrev i en meddelelse
news:aofe7s$26q6$1@news.cybercity.dk...
> Krabsen skrev:
> > Er der en venlig sjæl, der kan uddybe farerne ved DoEvents lidt?
>
> Naturligvis.
>
> > Jeg naive sjæl har opfattet DoEvents sådan, at den 'frigiver'
> Windows til at
> > gøre evt. andre processer færdige, inden den går videre.
>
> Nej, det er ikke Windows der er problemet (Windows ER et problem, men
> ikke i denne sammenhæng), det er den måde VB serialiserer (afvikler)
> tingene på.
>
>
.....klip...

---

Jan V. skrev:
> Men det var nu opdateringen jeg tænkte på - den kommer ikke uden
DoEvents.

Jo, for katten da!
Ved at bruge .Refresh metoden, som netop er til for det samme.

-------
Tomas

---

Glem det ... der skulle jo bare stå

LabStatus = "Now Copying AutoCAD Drawing" & " " & File1
LabStatus.refresh

Mvh Neo

---

"Neo.dk" <neo___dk@hotmail.removethis.com> skrev i en meddelelse
> Glem det ... der skulle jo bare stå
>
> LabStatus = "Now Copying AutoCAD Drawing" & " " & File1

LabStatus = "Now Copying AutoCAD Drawing " & File1

Lidt kortere....


--
/\ preben nielsen
\/\ prel@post.tele.dk

---

jow dee ....

tak !

Neo