Jag håller på med ett lite program i visualbasic men jag skulle behöva hjälp med hur jag ska få en funktion att starta vid kl 6:30 och en annan kl 16:00 Finns det nåt smartare sätt än att låta en timer kolla klockan varje minut och sen om den är 6:30 så startar den den funktionen?

ÄR det inte enkalre att skemalägga ett program som utför uppgiften?

NEJ du skall absolut inte använda timer och kolla stup i kvarten!

Här har du ett litet snabbhack på hur du kan göra. Du kan ju själv gör det lite snyggare.
<code>

Dim t As New System.Timers.Timer

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
AddHandler t.Elapsed, AddressOf TimerFired
Dim dblInt As Double = setInterval()
t.Interval = dblInt
t.Start()
End Sub
Public Sub TimerFired(ByVal sender As Object, ByVal e As System.Timers.ElapsedEventArgs)
'Här gör du det som skall göras 06:30 och 16:30
Beep()
t.Interval = setInterval()
End Sub
Private Function setInterval() As Double
'Kan vara fel här.... (Har inte kollat så noga)
If ((Now.Hour >= 16 And Now.Minute >= 30) Or (Now.Hour <= 6 And Now.Minute <= 30)) Then
'Nästa gång 06:30
setInterval = (DateDiff(DateInterval.Second, TimeSerial(Now.Hour, Now.Minute, Now.Second), TimeSerial(6, 30, 0)) * 1000)

Else
'Nästa gång 16:30
setInterval = (DateDiff(DateInterval.Second, TimeSerial(Now.Hour, Now.Minute, Now.Second), TimeSerial(16, 30, 0)) * 1000)
End If
End Function
</code>

...och den här tråden rör VB6 om man ser vilket forum den ligger i...

<b>...och den här tråden rör VB6 om man ser vilket forum den ligger i...</b>

Que ? Har Ni värmebölja i Göteborg ?
Verkar som du fått hjärnsläpp, han skriver i rätt Forum ! ;-) :-o

Jo, men Bennys svar är VB.NET...

/Johan

Här kommer mitt kodförslag:
<code>
Option Explicit

Private mTimeOut1 As Date
Private mTimeOut2 As Date

Private Function NextTimeOut(Value As Date, Time As Date) As Date
NextTimeOut = Fix(Value) + Time
If NextTimeOut < Value Then
NextTimeOut = DateAdd("d", 1, NextTimeOut)
End If
End Function

Private Function SkipWeekends(Value As Date) As Date
Select Case Weekday(Value, vbSunday)
Case vbSunday
SkipWeekends = DateAdd("d", 1, Value)
Case vbSaturday
SkipWeekends = DateAdd("d", 2, Value)
Case Else
SkipWeekends = Value
End Select
End Function

Private Sub Form_Load()
mTimeOut1 = SkipWeekends(NextTimeOut(Now, #6:30:00 AM#))
mTimeOut2 = SkipWeekends(NextTimeOut(Now, #4:30:00 PM#))
End Sub

Private Sub Timer1_Timer()
If mTimeOut1 < Now() Then
Call Function1
mTimeOut1 = SkipWeekends(NextTimeOut(Now, #6:30:00 AM#))
End If

If mTimeOut2 < Now() Then
Call Function2
mTimeOut2 = SkipWeekends(NextTimeOut(Now, #4:30:00 PM#))
End If
End Sub

Private Function Function1()

End Function

Private Function Function2()

End Function
</code>

Vidare fördrar jag att kalla <b> Kl 6:30 för 0.270830625</b>
Då stämmer det i hela världen oberoende av lokala inställningar.
<code>
MsgBox Format$(0.270830625, "hh:mm:ss")
</code>

ÄR det läsbart? JAg tycker inte det. Varför inte ange det som: #6:30:00 AM#
Vilket är det "korrekta" sättet att ange tidsangivelser i Visual Basic.

Din funktion är visserligen den som ger mest korrekta resultat, Andreas, men personligen tycker jag den är lite för grötig och omständlig för att riktigt vara användbar. Det är för mycket krångel med "fix()", etc.

Grötig och omständlig på vilket sätt? Om du talar om vad och varför du tycker det är gröttigt och omständig kan jag ta till mig din kritik.

Jag ser min kod som mycket användbar, återanvänbar. Då den är generellt utformad.

Är ett anrop till fix för mycket krångel?

Den är svår att förstå, på samma sätt som SvenPons 0.270830625 är svår att förstå.

Okej, kapslar du in den i en klass och så vidare så kan det göras snyggt och enkelt att hantera. Men tror du att en person som får koden i handen direkt skulle förstå vad den gör?

Jämför med exempelvis min ovan, eller en kapslad i stil med (pseudo):

<code>
dim tim as SpecialTimer

sub form_load
tim.AddTime(06:30)
tim.AddTime(16:00)
tim.Enabled
end sub

Sub tim_timer(alarmindex as long)
'skriv egen kod här
end sub
</code>

Där är det väsentligt lättare att förstå vad koden gör.

<b>på samma sätt som SvenPons 0.270830625 är svår att förstå.</b>

Mycket "Bull" kring detta.Huvudsaken jag förstår som gjort programmet.

Moster Märta som skall använda programmets .exefil bryr sig inte

Jag skriver inte koden för att Herr Hillqvist skall bli nöjd och glad,
Jag skriver för att optimera och anropa så få Functioner som möjligt.

Just i Timer programmet skulle jag laddat en Array med 1440 minutkonstanter
så kunden kan ställa in vakten vilken tid på dygnet han vill.

På samma sätt laddar jag Arrayer med alla Sinusvärde
jag behöver vid tunga Sin() beräkningar i Loop.

Problemet är att du enbart ser det ur hobbyprogrammerarens synvinkel, Sven. Utvecklar man för pengar så är det viktigt att det är lätt och går snabbt att förstå, vid framtida ändringar.
Varför?
-Det kan vara så att det inte är man själv som är inne i koden nästa gång.
-Det kan vara så att det har tagit lång tid sen man var inne i koden sen sist. Har man inte rört en kod på ett halvår-år, och gjort massor av annan kod emellan så är det väldigt lätt att glömma av hur den funkar.

Vad tror du själv - känns 0.270830625 eller 06:30 enklast att förstå om du tittar lite snabbt på samma kod om ett år?
Ganska snabbt ser du att det står någon form av tidsangivelse, men vet knappast vilken tid det står, och inte heller omedelbart varken hur du ska få fram vad det betyder eller hur du ska kunna ändra det.

På samma sätt är Hillqvists funktion långt ifrån självförklarande även om den är mest korrekt.

Du tvingar mig att åter använda ordet "Bull"

Jag slarvar aldrig med att skriva massor av Remarks.

Tar jag fram ett prog jag gjorde 1995 så står det massor av remarks
bla. hur jag fick 6:30 till 0.270830625

Programmerarens budord Nr 1: <b>Skriv Remarks Skriv Remarks Skriv Remarks !</b>
<code>
'1: Dygnet 00:00 till 23:59:59 kan skrivas som 0.99999
'2: det finns 24 timmar på ett dygn Dvs 0.99999/24 'nu har du 1 timme.
'3: 6:30 är decimal 6.5
'4: Dvs 0.99999/24 * 6.5
</code>
Ärendet är avslutat för min del. "Jag är ju äldst" ;-)

Det är ändå inte enkelt, vill man testa att flytta fram en minut måste man plocka fram miniräknaren. Dessutom behöver bra kod normalt sett inte kommentarer ;)

Det var ett väldans tjat om vilken lösning som är bäst.... jag förstår inte varför ni krånglar till det allihopa.

Det finns en färdig funktion i Windows API:t för ändamålet. Jag rekommenderar SetTimer som har en upplösning på en milisekund och som har ett omfång på närmare 50 dagar...

Så hela problematiken kan lösas med ett enda anrop på en enda kodrad... Det tycker jag är snyggast. :-)


// Johan

<b>På samma sätt är Hillqvists funktion långt ifrån självförklarande även om den är mest korrekt.</b>

På vilket sätt är inte min kod självförklarande?
<code>
Private mTimeOut1 As Date
</code>
Från Date ser jag att det är en tidpunkt. TimeOut talar om att det är en begränsad period. Att det kommer inträffa något efter att tidsperioden passerat.


<code>
Private Function NextTimeOut(Value As Date, Time As Date) As Date
NextTimeOut = Fix(Value) + Time
If NextTimeOut < Value Then
NextTimeOut = DateAdd("d", 1, NextTimeOut)
End If
End Function

Private Function SkipWeekends(Value As Date) As Date
Select Case Weekday(Value, vbSunday)
Case vbSunday
SkipWeekends = DateAdd("d", 1, Value)
Case vbSaturday
SkipWeekends = DateAdd("d", 2, Value)
Case Else
SkipWeekends = Value
End Select
End Function
</code>
Balck-box aspekterna. Man behöver hur en funktion gör det bara vad den gör. Kommentarer är givetvis självklara i en applikation. Där parametrar och resultat förklaras. Kanske en komentar som förklarar Fix(Value) tar bort klockslaget från ett datum. Men jag anser att de som programerar VB bör känna till hur datum hanteras.

Givetvis kan man lägga funktionerna i en modul eller ännu bättre utföra funktionen på ett objekt orienterat sätt. Men just för den här uppgicften är det overkill. Man skall inte överarbeta kod. Då slutför man inte projekt.


Dätt lämnar oss med följande kod:
<code>
Private Sub Form_Load()
mTimeOut1 = SkipWeekends(NextTimeOut(Now, #6:30:00 AM#))
mTimeOut2 = SkipWeekends(NextTimeOut(Now, #4:30:00 PM#))
End Sub


Private Sub Timer1_Timer()
If mTimeOut1 < Now() Then
Call Function1
mTimeOut1 = SkipWeekends(NextTimeOut(Now, #6:30:00 AM#))
End If

If mTimeOut2 < Now() Then
Call Function2
mTimeOut2 = SkipWeekends(NextTimeOut(Now, #4:30:00 PM#))
End If
End Sub
</code>
Där vi initierar variablerna i formload. Tar fram nästa tidpunkt utifrån aktuell tid:
<code>
NextTimeOut(Now, #6:30:00 AM#)
</code>
Hoppar över helger:
<code>
SkipWeekends()
</code>
Vid varje kontroll, kontrollerar vi om den förfallit:
<code>
If mTimeOut1 < Now() Then
</code>
Om den för fallit anropar funktionen:
<code>
Call Function1
</code>
Uppdatera tiden till nästa tidpunkt:
<code>
mTimeOut1 = SkipWeekends(NextTimeOut(Now, #6:30:00 AM#))
</code>


Jag tycker den kod är mycket tydlig. Men den är inte självförklarande, den förutsätter att du kan VB.
Jag tror det flesta VB programmerar kan sätta sig in i vad koden gör på 1 till 5 minuter och kunna lägga till ytterligare en tidpunkt som skall kontrolleras.

<b>Private Function NextTimeOut(Value As Date, Time As Date) As Date</b>

Varför har du Value som en parameter? Vad jag ser så skickar du alltid med Now och det finns väl heller ingen annan tidpunkt att utgå ifrån än just nu om man ska göra en timer-funktion?
Är det alltid samma sak man skickar in så är det väl lika bra att lägga den inne i funktionen.


Thomas

Har du ju rätt i. ;o)

Jag som ä fast i att generalisera.

Borde den inte heta något i stil med AddDateAndTime?

Hillqvist blev visst upprörd, verkar det som... =)

Jag ska förklara varför jag i det avseendet anser min vara bättre.
Koden jag hade skrivit ovan var:

<code>
sub Timer_Timer
static last_time
this_time=now()
if (last_time < 06:30) and (this_time > 06:30) then
dostuff
end if
last_time=this_time
end sub
</code>

Det är visserligen inte korrekt kod, det är ju pseudokod, men en riktig blir nästan identisk. Hur som helst tror jag att meningen
<code>if (last_time < 06:30) and (this_time > 06:30) then</code>
är mer uppenbar än din kod.

Jag tror inte din kod tar 1 minut att förstå, snarare 3-5. Men den här tar två sekunder att förstå, går i princip aldrig fel, är kort och enkel att utvidga eller bygga på. Jag vill inte behöva förklara för någon hur min kod fungerar, då är det ingen snygg kod.

Hur som helst är det naturligtvis inte någon av de här metoderna som är lämplig, utan den som Johan föreslår ovan. Men det är ju tämligen självklart.

AddDateAndTime tycker jag låter lite generellt. Lägga till datum och tid. Funktionen finner näst klockslag utefårn ett givet tidpunkt och klockslag.

Iofs, skumläste bara ltie

<b>Hillqvist blev visst upprörd, verkar det som... =)</b>
Jag skulle inte kalla det för det. Ser det mer som en intressant diskussion.

När jag tänker efter är det fel av mig att dra slutsatser om hur uppfattar något. Vi borde istället testa koden på ett gäng VB programmerare eller på anat sätt undersöka.

<b>Det är visserligen inte korrekt kod, det är ju pseudokod, men en riktig blir nästan identisk. Hur som helst tror jag att meningen</b>
<code>if (last_time < 06:30) and (this_time > 06:30) then</code>
<b>är mer uppenbar än din kod.</b>

Jag håller inte med dig där:
* Ju färre operationer som utförs på en rad, ju mer lättläst är koden. Du gör två jämförelser. Jag gör en.
* Variablern är väldigt lika vilket ger intrycket av att det är samma variabel som jämförs. Kräva att man tittar lite noggare.
* Tycker ordningen är fel. Man bör först kolla om klockan har passerat halv fem. Då deta är den primära operationen. Därefter lägga på vilkoret som kontrollerar att jämförelse gjorde innan halv fem.
* Logiken bakom kräver att man tänka efter lite extra. För att kontroller vad den gör och att den är korrekt.

För mig som mycket erfaren programmerar krävs det en del fundering innan man kontrollerat att den verkligen gör rätt.

Dessutom utförs massa med (onödiga) operationer vid varje jämförelse. Då min kod istället håller reda på tidpunkten för förfallet, minimerar jag mängden operationer.

Jag har försökt översätta din pseudokod till verklig kod:
<code>
Private Sub Timer1_Timer()
Dim this_time As Date
Static last_time As Date

this_time = Time

If (last_time < #6:30:00 AM#) And (this_time > #6:30:00 AM#) Then
Function1
End If

last_time = this_time
End Sub
</code>
Kompleterat med kontroll om det är helg:
<code>
Private Sub Timer1_Timer()
Dim this_time As Date
Static last_time As Date

this_time = Time

If (last_time < #6:30:00 AM#) And (this_time > #6:30:00 AM#) And Weekday(Date, vbMonday) < 6 Then
Function1
End If

last_time = this_time
End Sub
</code>

Sen kan jag tilläga att Static varibler har sämre prestanda en modulvariabler. Modulvariabler är att rekomendera.

Jag kan ju översätta min kod till pseudokod för att förtydliga logiken:
<info>
När formulär laddas:
Räkna ut tidpunkten när nästa 16:30 inträffar.
(Om du vill aktivera funktionen första gången timmer körs/programstart. Utelämnar du detta.)

När kontroll genomförs:
Har aktuell tid passerat tidpunkten
Kör vi funktionen
Räkna ut tidpunkten när nästa 16:30 inträffar.
</info>

Din kod översat till pseudokod:
<info>
När kontroll genomförs:
Hämta aktuell tid
Om tidigaretid inte passerat 16:30 och akuelltid passerat 16:30
Kör funktionen

Uppdatera tidigaretid till akuelltid
</info>

Blev så inspirerad av detta ämne så jag skall göra ett prog som slår i skeppsklockan.
Kanske någon annan tänder på iden.

Följande gäller till sjöss.
Man delar in dygnet i sjövakter om 4 timmar och slår Glas i skeppsklockan enl följ.

kl 08:00 ding ding ding ding ding ding ding ding Dvs åtta Glas
Kl 08:30 blir det bara ett ding
kl 09:00 ding ding
kl 09:30 ding ding ding
osv. dygnet runt. Nästa gång det blir 8 Glas är kl 12:00 sen börjar det om enl. ovan.

Obs dubbelslag kort uppe håll så nästa dubbel eller enkel. dvs ett litet sleep mellan.

Tacksam om Ni hittar en bra Bell.wav

<b>>* Ju färre operationer som utförs på en rad, ju mer lättläst är koden. Du gör två jämförelser. Jag gör en.
</b>
Tja... det är ju klart att det blir lite mer komplext om man har fler grejer på samma rad.
Men det blir väl knappast bättre av att slänga ut det i ytterligare en funktion. typ (IsBetween(06:30, LastTime, ThisTime)
Och jag tror inte att det känns väsentligt svårare att förstå än

if mTimeOut1 < Now()

<b>>* Variablern är väldigt lika vilket ger intrycket av att det är samma variabel som jämförs. Kräva att man tittar lite noggare.</b>
Vet jag inte vad jag ska svara på. Anser definitivt inte att det är bättre att ge två orimliga namn. Tittar man på jämförelsen så inser man nog väldigt snabbt att det måste vara olika variabler, eftersom de jämförs med samma värde...

<b>>* Tycker ordningen är fel. Man bör först kolla om klockan har passerat halv fem. Då deta är den primära operationen. Därefter lägga på vilkoret som kontrollerar att jämförelse gjorde innan halv fem. </b>
Eh...?
Det är väl en tämligen enkel grej att fixa. Det är ju ingen färdig kod jag skriver direkt.

<b>>För mig som mycket erfaren programmerar krävs det en del fundering innan man kontrollerat att den verkligen gör rätt.</b>
Och för mig som mycket erfaren programmerare krävs det en hel del fundering innan jag ens har orkat börja kolla på vad som menas med:
<code>
NextTimeOut = Fix(Value) + Time
If NextTimeOut < Value Then
NextTimeOut = DateAdd("d", 1, NextTimeOut)
End
</code>


<b>>Dessutom utförs massa med (onödiga) operationer vid varje jämförelse. Då min kod istället håller reda på tidpunkten för förfallet, minimerar jag mängden operationer. [...]
Sen kan jag tilläga att Static varibler har sämre prestanda en modulvariabler. Modulvariabler är att rekomendera.
</b>
Vi pratar om en funktion som utförs en gång i minuten och tar någon millisekund att göra. Optimering i det läget är totalt meningslöst. Sen är jag inte helt säker på det du säger... Jag gör två tilldelningar mer vid varje anrop, men dina funktioner gör väsentligt mycket mer arbete vid själva larmet.



I mitt tycke är det två punkter som är besvärliga i din kod. Dels kravet att uppdatera "NextTimeOut" vid varje "alarm", lätt att missa, inte uppenbart varför det behövs. Dels är det proceduren för att skjuta fram larmet en dag som är krånglig. Vidhåller att min med största sannolikhet är den koden som de flesta tycker är självklar vid första anblicken. Och den var jävligt lätt att skriva.

<b>
Tja... det är ju klart att det blir lite mer komplext om man har fler grejer på samma rad.
Men det blir väl knappast bättre av att slänga ut det i ytterligare en funktion. typ (IsBetween(06:30, LastTime, ThisTime)
Och jag tror inte att det känns väsentligt svårare att förstå än
</b>
Är det något fel med en funktion? Funktioner är ett bra sätt att koapsla kod som återanvänds.

Annars kan man bryta upp det till i flera if-satser.

<b>
Anser definitivt inte att det är bättre att ge två orimliga namn.
</b>
Är this_time ett rimligt namn? Blir väl översatt denna tiden. Jag tycker CurrentTime ger en tydligare skillnad på variablernas namn.

Man kan öka läsbarheten genom att skriva:
<code>
Private Sub Timer1_Timer()
Dim CurrentTime As Date
Static LastTime As Date
Const AlarmTime As Date = #6:30:00 AM#

CurrentTime = Time

If (CurrentTime >= AlarmTime) Then 'Är det efter half fem
If (LastTime < AlarmTime) Then 'Har vi redan kört funktionen
If Weekday(CurrentTime, vbMonday) < 6 Then 'Hoppa över helger
Function1
End If
End If
End If

LastTime = CurrentTime
End Sub
</code>
Denna koden är betydligt tydligare. Ger oxå möjlighet att komentera varje ifsats för att förtydliga vad de gör.

Sedan finns det en funktion man bör känna till. Om klockan är efter halv fem när programmet startas kommer funktionen att anropas.

<b>Optimering i det läget är totalt meningslöst.</b>
Jag håller med dig fullständigt i detta fallet. Men eftersom kod kan återanvändas på flera ställen i olika situationer vill jag för en djupare mer generel diskussion. Där man bör se vilka prestanda vinster förluster dinns det i koden.

<b>Dina funktioner gör väsentligt mycket mer arbete vid själva larmet.</b>
Då är det bättre att lägga fokus på minimera anropen vid kontroll än vid larm. Då propotionen mellan antalet körningarna av kontroll och larm gör kontrollen mer intressant.

<b>I mitt tycke är det två punkter som är besvärliga i din kod. Dels kravet att uppdatera "NextTimeOut" vid varje "alarm", lätt att missa, inte uppenbart varför det behövs. Dels är det proceduren för att skjuta fram larmet en dag som är krånglig. Vidhåller att min med största sannolikhet är den koden som de flesta tycker är självklar vid första anblicken. Och den var jävligt lätt att skriva.
</b>

Ett generlt sätt att kontrollera larm, påminelser och dylikt är att:
* Beräkna när den förfaller
* Kontrollera om den förfalit.
* När den förfallit beräkna nästa tidpunkt.

Att vi har olika åsikter om hur det bör utföras är tydligt. Jag tycker bara vi skall fortsätta dena tråden så länge avsikten är konstruktiv. Jag tror vi båda försvarar våra lösningar.

<b>>Att vi har olika åsikter om hur det bör utföras är tydligt. Jag tycker bara vi skall fortsätta dena tråden så länge avsikten är konstruktiv. Jag tror vi båda försvarar våra lösningar.</b>

Tja... jag har inte försvarat min lösning mer än i det avseendet att jag har sagt att jag tror att majoriteten skulle förstå den snabbare än man skulle förstå din. Sen ligger väl diskussionen långt över enskilda tecken, namn på variabler, eller uppdelning av if-satser?

Det där är detaljer, jag pratar om algoritmen, och vad algoritmen använder. Min algoritm gör två jämförelser per tick (för ett alarm). Jämförelserna är hyfsat enkla att förstå, funktionen är ytterligt kort, och den gör rätt i alla fall, utom några extrema specialfall.

Din algoritm gör en jämförelse per tick, men vid själva alarmet två funktionsanrop för att sätta "nästa alarm". Ena av funktionsanropet är hyfsat svårt att förstå. Själva principen att som användare av funktionen själv behöva sätta nästa stopp är besvärligt, enligt mig.

Nåväl, våra funktioner passar bra till helt olika grejer. Din kan vara användbar i system där väldigt skumma grejer kan hända, eller i ett tillfälle när man vill hitta väldigt många "nästa tid" av olika anledningar, etc.

Men som kod för en människa att titta på och omedelbart använda är min nog bättre.

<b>>Då är det bättre att lägga fokus på minimera anropen vid kontroll än vid larm. Då propotionen mellan antalet körningarna av kontroll och larm gör kontrollen mer intressant.</b>
Men snälla Andreas... Vi pratar om något som utförs en gång per minut. Även om det hade utförts en gång per sekund hade det inte gått att märka.


Det mest generella, effektiva och lämpliga sättet är och förblir kod i stil med:
SetTimeOut(Funktion, Tid)
eller
SetRegularTimeOut(Funktion, Tid, Intervall)

Ska man göra en egen är jag övertygad om att man ska rikta in sig på att få den så enkel som möjligt.

Varför var det ingen som hakade på Andreas förslag i början med att använda schemaläggaren istället?

Skapa en applikation som tar ett kommondoradsargument som avgör vad som skall göras och använd denna i schemaläggaren. Startar man programmet utan argumentet så öppnas GUI:et som vanligt.

På detta sätt fungerar det även om datorn varit i vilo- eller vänteläge vilket jag är osäker på att ovanstående lösningar gör.

--Varför var det ingen som hakade på Andreas förslag i början med att använda schemaläggaren istället?

Om du studerar mer eller mindre alla svar jag skrivit i denna tråden så ser du att jag hela tiden ansett att det är det man bör göra...

*Snyft* Niklas mobbar mig. Han är en stygg pojke.

;o)

Niklas,

Du undrar:
<b>"Varför var det ingen som hakade på Andreas förslag i början med att använda schemaläggaren istället?"</b>

Jag kan hålla med om att denna är snygg från flera aspekter och att den kan fungera bra i vssa lägen. Den största nackdelen med att lita på schemaläggaren är att det kan bli väldigt opålitligt. Om man inaktiverar schemaläggaren på datorn så kommer ens program aldrig att köras vid den aktuella tidpunkten.

Så frågan är mest hur kritiskt det är. Om det inte gör något att man missar ibland eller på vissa datorer så kan man mycket väl lita på schemaläggaren.

Om det däremot är viktigt att kunna hålla koll på detta så bör man ha det inom sitt egna program.

Dock återstår det i slutändan ändå problemet med att datorn eller programmet kan vara avstängt så för de fallen krävs det andra metoder för att säkerställa att det blir rätt. Men eftersom det är en helt annan historia så tar vi inte det här,..


// Johan

Vill bara poängtera att det var Martin Adrian som skrev meningen "Varför var det ingen som hakade på Andreas förslag i början med att använda schemaläggaren istället?".

Jag citerade den, men min flickväns dator klarar inte < och > (fråga inte...) så jag orkade inte fixanågot bättre citat.

Johan,

Tycker ditt resonemang med schemaläggaren låter lite konstigt. "Om det inte gör något att man missar ibland eller på vissa datorer så kan man mycket väl lita på schemaläggaren".

Jag skulle ju säga att det är säkrare med schemaläggaren eftersom den automatiskt hanterar många saker som händer (viloläge, omstart, ingen användare inloggad, avbryt om programmet hänger sig etc).

Ett program kräver ju att man själv skriver koden som hanterar alla möjliga fall. Som synes i den här tråden är det ju inte helt trivialt att skriva koden för att uföra nåt vid samma tidpunkt varje dag. Dessutom måste man ju se till programmet startas automatiskt, inte körs i flera instanser mm.

Har roat mig med att göra ett prog enl min och Thomas Romans princip.
Jag har kört det nu i 2 dygn och det funkar "klockrent" "häpp"

Programmet lutar sig mot Timer1.
Skulle var förbaskat roligt om någon tog upp samma prog och gjorde det
enl den teknik som Ni förordar. (schemaläggaren)

Programarkivet:Skeppsklocka Tidvakt

Sven Åke,

Tänk om ingen använder datorn och att den går in i strömsparläge eller strömmen går och datorn startar om. Den som har hundvakten lär ju inte bli särskilt glad om klockan aldrig slår 8 glas :-)

Med schemaläggaren kan man ju enkelt bestämma hur man vill hantera dessa situationer.

Så här skulle mitt program kunna se ut

<code=vbscript>
If WScript.Arguments.Length = 1 Then
For ii = 1 To WScript.Arguments(1)
' Spela något ljud. (Vet inte på rak arm hur man gör det i wsh)
PlaySound "bell.wav"
' Vänta kort mellan udda och långt mellan jämna
WScript.Sleep(1000 - 600 * (ii Mod 2))
Next ii
End If
</code>

Sen skapar jag olika scheman som anropar scriptet ovan var fjärde timma.
glas.vbs 1
glas.vbs 2
...

Men Vaaaa fae... djä... helvetes djä.... Blåsvidda helvete !!!

Du tror väl inte en sjöman skulle lita på en dator när det gäller vaktalösning.

Vi har ett sandtidur som Vi vänder på var 4:e timme,faen hämtar den ur vakten
som inte håller reda på tiduret.Sen slår Vi i klockan enl dom regler jag beskrivit.

Exemplet är till för dig som landkrabba för att få känslan hur det kan låta ombord.

>Du tror väl inte en sjöman skulle lita på en dator när det gäller vaktalösning.

Det var ju lite som var min poäng.

I den ursprungliga frågan skulle man ju styra något med ett relä vilket är svårare att ersätta med timglas. Därför behöver man ha ett system som man åtminstonde vet när det fungerar och inte.

Schemaläggaren har säkert sina svagheter men de är iallafall kända. Om man skriver egen kod för att väcka datorn, starta om programmet vid krash osv så måste ju den koden testas på en massa olika sätt vilket tar tid.

Martin,

<b>"Tycker ditt resonemang med schemaläggaren låter lite konstigt."</b>
<b>"Jag skulle ju säga att det är säkrare med schemaläggaren eftersom den automatiskt hanterar många saker som händer."</b>

Det håller jag med om, men det var inte det som var min poäng.

Vad jag menade var att om schemaläggaren är avstängd, pga virus, klantig användare eller dylikt så kommer aldrig ens program att aktiveras igen. Det var därför jag menade att när man väl dragit igång sin instans av sitt program att man borde hålla det semi-aktivt och själv kontrollera när tiden är inne.

Schemaläggaren är utmärkt att använda om man vet med 100% säkerhet att den är igång.

// Johan

När man läser dom senaste inläggen kan man konstatera. Djä... massa "bullshit"

SvenPon,

Menar du dina egna senaste inlägg...?

// Johan

> SvenPon,

> Menar du dina egna senaste inlägg...?

> // Johan

Vem annars?

<b> Eugen när du startade denna tråd visste du inte vilket elände du startat.
men roligt har det varit </b>

*LoL* Jag har lyckats få upp Johan på steget så han "ekar"

Vill se en shedular lösning från dig Johan som slår Glas enl min beskrivning.
se Programarkivet:Skeppsklocka Tidvakt
Tomma tunnor ekar bäst *LOL*

SvenPon,

<b>"Vill se en shedular lösning från dig Johan"</b>

Intressant förfrågan du har. Eftersom jag själv förespråkat att använda windows API:et och SetTimer så hade jag möjligtvis förväntat mig att det var det du skulle fråga om. Fast där har jag ju redan svarat med all inforation tidigare i tråden, inklusive länkar till exempel.

Då jag själv inte pratat mig särskilt varm för scheduler lösningen så har jag inget på lager. Men kanske du kan be någon av dem i tråden som vurmat för detta.

Läsa är silver, läsa korrekt är guld...

// Johan

Oki på det.
Men ! så för fae...., visa mig en lösning på detta med en programrad.

"Tomma tunnor skramlar mest"

Programarkivet:Skeppsklocka Tidvakt

<b>Vi har ett sandtidur som Vi vänder på var 4:e timme</b>

Korrektion: Vi vänder på det varje halvtimme ;-)

Programarkivet:Skeppsklocka Tidvakt

Nu ha rjag gjort ett program det blev så här

Option Explicit
Dim checkTime As Single
Dim hDag As String
Dim Läge As Byte
Rem Tiden minuter * 0,0006944375
Const Tid1 = 659 'Kl 7:00 - 1 min
Const Tid2 = 1630 'Kl 16:30




Private Sub Command1_Click()
CLOSECOM
End
End Sub

Private Sub Command2_Click()
Läge = Läge + 1
If Läge = 1 Then Label1.Caption = "AUTO": Timer1.Enabled = True: Timer1_Timer
If Läge = 2 Then Label1.Caption = "ON": Timer1.Enabled = False: Label1.ForeColor = &HFF0000: DTR 0
If Läge = 3 Then Label1.Caption = "OFF": Timer1.Enabled = False: Läge = 0: Label1.ForeColor = &H0&: DTR 1




End Sub

Private Sub Form_Load()
OPENCOM ("COM1,1200,N,8,1")
Command2_Click
End Sub

Private Sub Timer1_Timer()
'Interval 64000
checkTime = Format$(Time, "hmm")
hDag = Format$(Date, "ddd")
If hDag = "lö" Or hDag = "sö" Then Label1.ForeColor = &H80FF&: DTR 1: Exit Sub
If checkTime > Tid1 And checkTime < Tid2 Then
Label1.ForeColor = &HC000&
DTR 0
Else
Label1.ForeColor = &HFF&
DTR 1
End If

Lite synpunkter har jag !
<code>
Private Sub Timer1_Timer()
'Interval 59888
checkTime = Format$(Time, "h:mm")
hDag = Format$(Date, "ddd")
If hDag = "lö" Or hDag = "sö" Then
Label1.ForeColor = &H80FF&
DTR 1
Exit Sub
End If
If checkTime > Tid1 And checkTime < Tid2 Then
Label1.ForeColor = &HC000&
DTR 0
Else
Label1.ForeColor = &HFF&
DTR 1
End If
</code>

SvenPon,

<b>"Men ! så för fae...., visa mig en lösning på detta med en programrad."</b>

jag förstår inte vad det är för jobbigt med att läsa det exempel som fanns i de länkar jag postat tidigare. Jag ser ingen anledning att dubblera mina svar.

Jag har inget mer att tillägga på detta ämne, så ta nu chansen att vara den kärring som får sista ordet... ;-)

// Johan

Om man vill skriva samma sak, fast bättre:
<code>
Option Explicit

Private Enum State
stateAuto
stateOn
stateOff
LengthOfState
End Enum

Rem Tiden minuter * 0,0006944375
Const Tid1 = #7:00:00 AM# 'Kl 7:00
Const Tid2 = #4:30:00 PM# 'Kl 16:30

Private Sub Command1_Click()
CLOSECOM
Unload Me
End Sub

Private Sub Command2_Click()
Läge = (Läge + 1) Mod stateLengthOfState
Select Case Läge
Case stateOff
Label1.Caption = "OFF"
Timer1.Enabled = False
Label1.ForeColor = &H0&
DTR 1
Case stateAuto
Label1.Caption = "AUTO"
Timer1.Enabled = True
Timer1_Timer
Case stateOn
Label1.Caption = "ON"
Timer1.Enabled = False
Label1.ForeColor = &HFF0000: DTR 0
End Select
End Sub

Private Sub Form_Load()
OPENCOM "COM1,1200,N,8,1"
Command2_Click
End Sub

'Interval 64000
Private Sub Timer1_Timer()
Dim checkTime
Dim hDag As VbDayOfWeek

checkTime = Time

Select Case Weekday(Date)
Case vbSaturday, vbSunday
Label1.ForeColor = &H80FF&
DTR 1
Case Else
If checkTime >= Tid1 And checkTime < Tid2 Then
Label1.ForeColor = &HC000&
DTR 0
Else
Label1.ForeColor = &HFF&
DTR 1
End If
End Select
End Sub
</code>
Nu fungerar koden även för de som inte har svenska språk på operativsystemet.