[vb.net] Invoke werkt niet

[Damic]

Ik probeer al geruime tijd om (in het begin een listbox nu) een listview te vullen via verschillende threads maar welk voorbeeld dat ik ook volg, de invoke werkt niet. De laatste how to dat ik heb gevolgt is die van MS zelf: MSDN: How to: Make Thread-Safe Calls to Windows Forms Controls.

Ik heb een break point op de debug.writeline gezet en daar komt ie nooit in

Relevante code:

Visual Basic .NET:

Delegate Sub UpdateLogDelegate([DayStart] As String, [DayStop] As String)
    Public Sub UpdateLog(Optional DayStart As String = "NOW", Optional DayStop As String = "NOW")
        If lvLog.InvokeRequired Then
            Debug.WriteLine("updatelog.invoke")
            Invoke(New UpdateLogDelegate(AddressOf UpdateLog), New Object() {[DayStart], [DayStop]})  'New Action(Of String, String)(AddressOf UpdateLog), DayStart, DayStop) 
        Else
            RefreshLog([DayStart], [DayStop])
        End If
    End Sub

    Private Sub RefreshLog(Optional DayStart As String = "NOW", Optional DayStop As String = "NOW")
        '-set filter
'... al de rest van de code
end sub

Wat gebeurd er:
in de threads roep ik een functie aan die als het log venster openstaat de Updatelog() sub aanroept. Deze zou moeten checken of het nodig is om de listview te invoken of niet en dat gebeurt dus niet. De if stuurt de data rechtstreeks door naar de RefreshLog() sub en dan zie je pas iets verschijnen als ie terug in de main thread zit.
Nu is het wel zo dat de RefreshLog() sub word uitgevoerd want ik zien wel dat ie de data ophaalt en de laatste id naar het debug venster schrijft.

Dus nu mijn vraag: wat gaat er verkeerd, want error's krijg ik niet


Relevante software:
VS2017 community, win10 (op win7 werkte het ook niet)

[ Voor 4% gewijzigd door Damic op 05-06-2017 22:34 ]

[Down]

Als je een breakpoint op regel 3 zet ben je er denk ik zo achter. Dan kun je controleren wat de waarde van InvokeRequired is. Tevens kun je dan bepalen of het hele event überhaupt wordt aangeroepen of niet.

[ Voor 7% gewijzigd door Down op 05-06-2017 22:43 ]

[Damic]

Invokerequired blijft altijd false want hij gaat nooit in de True kant van de if.

Ik ben nu aan't zien of ik toevallig een exception heb afgezet.

[Down]

Wat is dan het probleem? Ofwel je roept de code aan op de UI thread ofwel asynchroon. Als InvokeRequired altijd false blijft is het eerste het geval. Dan kan de hele invoke constructie er uit. Je kunt in de debugger ook controleren welke thread het event veroorzaakt en welke het event ontvangt d.m.v. System.Threading.Thread.CurrentThread.ManagedThreadId.

[Anoniem: 917165]

Dat weet je pas, als je er een breakpoint op zet en kijkt wat er in zit. Wat is het type? Is het wel een boolean? of bv. 1 of 0? Dan faalt je functie ook al.

Beter is

code:

if (lvLog.InvokeRequired != false) ....

of yoda:

code:

if (false != lvLog.InvokeRequired) ...

[Damic]

@Down ik open het logboek vesnter in de main thread en start daarna een backgroundworker (bgw) en in die bgw start ik nog eens 3 sub threads die allemaal die functie aanroepen dus ik vermoed dat het asynchrone is.
*nu even zoeken waar ik die exception zet want in mijn lijst van common exceptions staat ie niet. pfff

@Anoniem: 917165 InvokeRequired is een boolean en ik volg het voorbeeld van MS.

[Anoniem: 917165]

@Anoniem: 917165 InvokeRequired is een boolean en ik volg het voorbeeld van MS.

Kennelijk toch niet helemaal. Want bij MS werkt het wél.

[Damic]

Ok ik doen 1 ding anders, maar waarom werkt het dan niet in de bgw?

Wat ik anders doen is de nieuwe threads aanmaken, dat was:

Visual Basic .NET:

                   Dim sopthr As Thread = New Thread(AddressOf SendOnePage)
                    With sopthr
                        .IsBackground = True
                        .Start()
                    End With

dat heb ik veranderd naar

Visual Basic .NET:

                   Dim sopthr As Thread = New Thread(new threadstart(AddressOf SendOnePage))
                    With sopthr
                        .IsBackground = True
                        .Start()
                    End With

Edit: resultaat hetzelfde
Edit2: ik heb even de threads in het oog gehouden + een breakpoint op de invokerequired gezet en er klopt iets niet.
Als ie in de maintread zit geeft ie mooi aan dat alles normaal is en invokerequired =false.
Als in in een sub thread zit geeft ie dat ook aan maar invokerequired blijft false aangeven

Zou het kunnen dat de backgroundworker toch iets verkeerd doet waardoor lvlog de verkeerde threadid meekrijgt?

[ Voor 25% gewijzigd door Damic op 06-06-2017 00:08 ]

[RobIII]

Anoniem: 917165 schreef op maandag 5 juni 2017 @ 22:50:
Dat weet je pas, als je er een breakpoint op zet en kijkt wat er in zit. Wat is het type? Is het wel een boolean? of bv. 1 of 0? Dan faalt je functie ook al.

Euh, VB.Net is een strong typed taal; geen weak typed taal als PHP of JS. Er kán dus alleen maar true/false in InvokeRequired zitten want diens type is bool.

[ Voor 13% gewijzigd door RobIII op 06-06-2017 00:19 ]

[Anoniem: 917165]

RobIII; niet correct. Ik weet dat VB strict typed is, ik weet echter niet waar die InvokeRequired vandaan komt. Dat kan ook een zelf gedefinieerde functie zijn, mss wordt ie wel ergens overloaded met een ander type, enzovoort.

Je zou niet de eerste zijn die een aanname over een type van een variabele doet, omdat iemand een vrij veelkomende naam van een bepaald type, als naam gekozen heeft voor een ander type.

Verder doet TS een aaname. Hij zegt 'hij moet false zijn, want..".

Stel nu eens dat de fout in het schrijven naar het debuglog zit. Dat DAAR iets in misgaat. Dan faalt TS al in zijn anamnese.

Daarom. Breakpoint zetten op die lijn, en kijken wat er écht inzit. Niet zomaar iets aannemen.

Dat was een beetje mijn punt.

//edit
en zie daar.. er is een breakpoint gezet en TS heeft nieuwe info en een richting om in te zoeken.

[ Voor 6% gewijzigd door Anoniem: 917165 op 06-06-2017 00:23 ]

[RobIII]

Anoniem: 917165 schreef op dinsdag 6 juni 2017 @ 00:22:
RobIII; niet correct. Ik weet dat VB strict typed is, ik weet echter niet waar die InvokeRequired vandaan komt. Dat kan ook een zelf gedefinieerde functie zijn, mss wordt ie wel ergens overloaded met een ander type, enzovoort.

TS geeft aan dat lvLog een ListView is en diens InvoleRequired property is prima gedocumenteerd
Als 'ie al overloaded was (wat volgens mij helemaal niet kan) is dat een omissie van TS.

[ Voor 9% gewijzigd door RobIII op 06-06-2017 00:26 ]

[sig69]

InvokeRequired is gewoon een boolean, zoals in de documentatie staat.

[Anoniem: 917165]

Dus ik inherit een ListView en overload de InvokeRequiredfunctie met een string.

En dan? Polymorfisme ring a bell?

Hoe dan ook, offtopic en het punt was meer dat ie wél een breakpoint moest zetten en niet zomaar iets moest aannemen.

[ Voor 34% gewijzigd door Anoniem: 917165 op 06-06-2017 00:27 ]

[RobIII]

Anoniem: 917165 schreef op dinsdag 6 juni 2017 @ 00:26:
Dus ik inherit een ListView en overload de InvokeRequiredfunctie met een string.

Doe eens? Compiled het?
De signature moet verschillen wil je iets overloaden. Ring a bell, wijsneus?

[ Voor 15% gewijzigd door RobIII op 06-06-2017 00:30 ]

[Damic]

@Anoniem: 917165 je hebt daar gelijk in maar dat doen ik niet.

Ik heb eventjes wat verder gelezen en blijkbaar is dat het standaard gedrag bij de backgroundworker, als je een call wil doen naar buiten de thread van de bgw moet je ReportProgress(integer,object) aanroepen en kom je terecht in ProgressChanged(). dat is wel heel veilig

>>>Moest er iemand anders toch iets anders vinden mag je dat altijd melden<<<

Dat word dus herschrijven naar een echte thread

[ Voor 9% gewijzigd door Damic op 06-06-2017 00:31 ]

[Anoniem: 917165]

RobIII schreef op dinsdag 6 juni 2017 @ 00:27:
[...]

Doe eens? Compiled het?

Waarom niet? Het is een functie die overloadbaar is, het kan zijn, ik weet niet hoe goed de VB.net compiler is, ik ben meer van C/C++, dat je een melding over ambuguiteit krijgt. Maar zover ik kan zien, is die functie wel degelijk overloadbaar en had het scenario theretisch gekund.

Ik geef meteen grif toe; het was hier dus niet van toepassing.

Het zou zelfs nog kunnen dat het hele object niet geinstantieerd is en je NULL terugkrijgt en een exceptie, die elders foutief wordt afgehandeld.

Pas als je een breakpoint OP HET JUISTE PUNT zet, kom je er achter. Je zet een breakpoint niet na een if en dan maar aannemen dat die if een bepaald resultaat heeft. Dát was het punt wat ik wilde maken.

@TS gezien zijn laatste reactie:

is een simpele mutex geen optie?

[ Voor 4% gewijzigd door Anoniem: 917165 op 06-06-2017 00:30 ]

[Damic]

@Anoniem: 917165 Dat gaan ik eens bekijken, ben niet zo bekent met threads.

[Anoniem: 917165]

Ik ken de VB.net implementatie ervan niet en ook geen idee of het in dit geval de beste oplossing is, maar het kan de moeite waard zijn om naar te kijken.

Met een mutex (mutal exclusion) kun je voorkomen dat twee stukken code (bv, het updaten van info op het scherm) tegelijk draaien. Zo kun je dus iets thread-safe maken.

Intuitief zeg ik dat het in dit geval niet het geëigende middel is, maar het is een onderzoekje waard in jouw situatie.

[Damic]

Ik was juist een edit aan't typen anyway: ik denk niet dat een mutex in mijn geval van toepassing is. Zodra ik in de sub thread gaan, gaan ik een waarde zetten dat de thread bezig is. Het is alleen als de thread gedaan is dat er nog wat afhandeling moet gebeuren (opvangen met asyncresult()).

[Woy]

Maar wat is het probleem nou precies? Je gebruikt een background worker en de ProgressChanged en RunWorkerCompleted callbacks zijn al gesynchroniseerd met de UI thread. Dan is het ook logisch dat InvokeRequired altijd false is in die calls. Het hele idee van de BackgroundWorker is juist dat die al de UI synchronisatie al afhandelt.

[Damic]

Dat er tijdens de bgw niets verschijnt in de listview.
Ow ik gebruik progresschanged() niet.

[ Voor 26% gewijzigd door Damic op 06-06-2017 09:21 ]

[farlane]

Anoniem: 917165 schreef op maandag 5 juni 2017 @ 22:50:
Dat weet je pas, als je er een breakpoint op zet en kijkt wat er in zit. Wat is het type? Is het wel een boolean? of bv. 1 of 0? Dan faalt je functie ook al.

Beter is

code:

if (lvLog.InvokeRequired != false) ....

of yoda:

code:

if (false != lvLog.InvokeRequired) ...

toon volledige bericht

Dus ik inherit een ListView en overload de InvokeRequiredfunctie met een string

Ook in C++ is dat onzin, je kunt niet een functie die als bool is gedefinieerd overloaden als iets anders zonder de signature te veranderen.

Jouw voorbeeldcode introduceert alleen maar ruis en is m.i. slechter dan zonder de expliciete check.

[farlane]

Damic schreef op dinsdag 6 juni 2017 @ 09:20:
Dat er tijdens de bgw niets verschijnt in de listview.
Ow ik gebruik progresschanged() niet.

Werkt je RefreshLog wel dan? Daar komt ie uiteindelijk toch in, background thread of niet. Waarschijnlijk wordt je ListView niet gerefreshed o.i.d

[Woy]

Damic schreef op dinsdag 6 juni 2017 @ 09:20:
Dat er tijdens de bgw niets verschijnt in de listview.
Ow ik gebruik progresschanged() niet.

Het zou mij niet verbazen als je dan de UI Thread op de een of andere manier geblokkeerd hebt. Hoe gebruik je de background worker? Het is de bedoeling dat je het werk verzet in de DoWork callback.

[Damic]

@farlane ja daar komt ie in, dat zien ik aan de debug.writeline()s lijn 7 (zit in de functie) en 10

Visual Basic .NET:

    Private Sub RefreshLog(Optional DayStart As String = "NOW", Optional DayStop As String = "NOW")
        If Not IsDate(DayStart) Then DayStart = Date.UtcNow.Day & "/" & Date.UtcNow.Month & "/" & Date.UtcNow.Year & " 00:00:00"
        If Not IsDate(DayStop) Then DayStop = Date.UtcNow.Day & "/" & Date.UtcNow.Month & "/" & Date.UtcNow.Year & " 23:59:59"
        '-set filter
   '...
        '-get the data
        Using dt As DataTable = dblog.GetData("SELECT LogId, Message, LogType, UTCtime FROM tblLog WHERE " & filter & "LogId> " & LastLogId & " and (UTCtime BETWEEN " & ToUnix(Date.Parse(DayStart)) & " AND " & ToUnix(Date.Parse(DayStop)) & ") order by UTCtime ASC;")
            If dt.Rows.Count <= 0 Then Exit Sub
            LastLogId = CInt(dt.Rows(dt.Rows.Count - 1).Item("LogId"))
            Debug.WriteLine("LastId: " & LastLogId)
            Dim col As Color
            pbLoad.Value = 0
            pbLoad.Maximum = dt.Rows.Count
            For i = 0 To dt.Rows.Count - 1
                If Not pbLoad.Visible Then pbLoad.Show()
                Try
                    pbLoad.PerformStep()
                    lvLog.Items.Add(FromUnix(CInt(dt.Rows(i).Item("UTCtime"))).ToString("dd/MM/yyyy HH:mm:ss UTC"))
'...set color
                    lvLog.Items(lvLog.Items.Count - 1).SubItems.Add(dt.Rows(i).Item("Message").ToString).BackColor = col
                    lvLog.Items(lvLog.Items.Count - 1).UseItemStyleForSubItems = False
                Catch ex As Exception
                    Debug.WriteLine("RefreshLog: " & ex.Message)
                End Try
            Next
        End Using
        lvLog.EnsureVisible(lvLog.Items.Count - 1)
        pbLoad.Hide()
    End Sub

@Woy hoe bedoel je dat ik die lock? Ik kan alles doen in de main thread.
Ik start de bgw vanuit een timer en zolang bgw.isbusy dan gaat ie uit het timer event.
Ondertussen word al het werk verzet in de bgw_dowork()

[barfieldmv]

Aangezien van een afstandje debuggen heel moeilijk is zou ik een heel andere oplossing kiezen.

Plaats in de applicatie een shared List(of String) en vul deze vanuit het werkende proces.
Plaats een timer op het form dat elke seconde(200ms is een mooi minimum) het scherm updated met de laatste meldingen.

Voeg nu wat locking toe om de List(of String) zodat je geen multi threaded problemen krijgt en je hebt een werkende applciatie

[farlane]

Damic schreef op dinsdag 6 juni 2017 @ 09:47:
@farlane ja daar komt ie in, dat zien ik aan de debug.writeline()s lijn 7 (zit in de functie) en 10

Visual Basic .NET:

....

Doe eens al die code weg en maak een nieuwe listitem aan met een vaste tekst en voeg dat toe. Kijk of dat werkt.

Je betrekt werkelijk de hele wereld bij het toevoegen van een listitem en concludeert dat het dan wel aan het voorbeeld van MS zal liggen, maar er kunnen nog 1 miljoenmiljard andere dingen fout gaan in deze code.

[Woy]

Sowieso is het natuurlijk een slecht idee om in de RefreshLog die op de UI thread draait weer DB access te gaan doen. Dat is een blocking IO actie die je typisch niet op de UI thread wil doen.

Ik zou eerder kijken om gebruik te maken van iets van een ConcurrentQueue en die in het ProgressChanged event uit te lezen in je ListView te stoppen.

Maar sowieso is het feit dat lvLog.InvokeRequired altijd true is een indicatie dat je daadwerkelijke werk al op de UI thread plaatsvind, en dus waarschijnlijk de UI thread blokkeert waardoor de daadwerkelijke UI updates pas plaatsvinden op het moment dat al het werk gedaan is.

[ Voor 28% gewijzigd door Woy op 06-06-2017 10:56 ]

[Damic]

Mmmh ok, dat zal dan iets zijn voor de toekomst.
Ik heb het nu opgelost door in het timer event de threadid op te slaan in een variable en als ik iets aan het listview toevoeg gaat ie eerst controleren of dat ik nog wel op de mainthread zit. Zoja word de listview geupdate, zo nee moet ie maar wachten op de bgw_progresschanged() en doen ik het daar.

[Woy]

Damic schreef op dinsdag 6 juni 2017 @ 12:26:
Ik heb het nu opgelost door in het timer event de threadid op te slaan in een variable en als ik iets aan het listview toevoeg gaat ie eerst controleren of dat ik nog wel op de mainthread zit.

Gefeliciteerd, je hebt zojuist InvokeRequired opnieuw geimplementeerd

C#:

public bool InvokeRequired {
            get {
  
                using (new MultithreadSafeCallScope())
                { 
                    HandleRef hwnd; 
                    if (IsHandleCreated) {
                        hwnd = new HandleRef(this, Handle); 
                    }
                    else {
                        Control marshalingControl = FindMarshalingControl();
  
                        if (!marshalingControl.IsHandleCreated) {
                            return false; 
                        } 
 
                        hwnd = new HandleRef(marshalingControl, marshalingControl.Handle); 
                    }
 
                    int pid;
                    int hwndThread = SafeNativeMethods.GetWindowThreadProcessId(hwnd, out pid); 
                    int currentThread = SafeNativeMethods.GetCurrentThreadId();
                    return(hwndThread != currentThread); 
                } 
            }
        }

[Damic]

Jaja maar het mijne werkt

[Woy]

Damic schreef op dinsdag 6 juni 2017 @ 12:47:
Jaja maar het mijne werkt

De officiele implementatie ook De enige reden waarom het bij jou misschien niet goed werkt is omdat je wat anders fout doet. ( Maak je de ListView bijvoorbeeld aan buiten de UI thread? )

[farlane]

Damic schreef op dinsdag 6 juni 2017 @ 12:26:
Zoja word de listview geupdate, zo nee moet ie maar wachten op de bgw_progresschanged() en doen ik het daar.

Waarom dan niet al die shit weglaten en meteen een ReportProgress?

[Damic]

Listview word mee aangemaakt (met de rest van de controls) als het form opstart.

maar volgens mij heb ik het al eens gezegd: de bgw laat het niet toe om dingen in de main thread aan te passen. Dit heb ik getest via een probeer project waar de verschillende mogelijkheden zijn in verwerkt.

@farlane omdat niet alles in de bgw gebeurt

[farlane]

Damic schreef op dinsdag 6 juni 2017 @ 18:01:
@farlane omdat niet alles in de bgw gebeurt

Want waar gebeurt nog meer? Aan andere backgroundworkers kun je dezelfde callback plakken en als het in je form is kun je rechtstreeks de callback handler aanroepen.

[sig69]

Damic schreef op dinsdag 6 juni 2017 @ 18:01:
Listview word mee aangemaakt (met de rest van de controls) als het form opstart.

maar volgens mij heb ik het al eens gezegd: de bgw laat het niet toe om dingen in de main thread aan te passen. Dit heb ik getest via een probeer project waar de verschillende mogelijkheden zijn in verwerkt.

@farlane omdat niet alles in de bgw gebeurt

In de DoWork eventhandler bedoel je? Dat gaat prima:

C#:

private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
    for(int i = 0; i  <10; i++)
    {
        AddItem(i);
                
        Thread.Sleep(1000);
    }
}

private void AddItem(int i)
{
    if (InvokeRequired)
    {
        Invoke(new Action(() => AddItem(i)));
        return;
    }

    listView1.Items.Add(i.ToString());
}

[Damic]

Wut?

[sig69]

Jij zegt:

de bgw laat het niet toe om dingen in de main thread aan te passen

Bovenstaande voorbeeld laat zien dat het wel kan.

[Damic]

Vertaalt niet zo goed naar vb.net

[sig69]

Daar zijn zat tools voor online.

[RobIII]

Damic schreef op dinsdag 6 juni 2017 @ 19:46:
Vertaalt niet zo goed naar vb.net

Los van een puntkomma her-en-der en wat andere kleine syntax dingetjes is de strekking wel duidelijk lijkt me. Boeie hoe het eruit ziet in C#; voor VB.Net geldt exact hetzelfde.

[Damic]

Als ik het in een converter gooi krijg ik dit:

Visual Basic .NET:

Private Sub AddItem(i As Integer)
    If InvokeRequired Then
        Invoke(New Action(Function() AddItem(i)))
        Return
    End If

    listView1.Items.Add(i.ToString())
End Sub

En dit is wat ik er van maak


Als ik even verder nadenk moet die Function niet Sub zijn eens testen.

Maarja dan kom ik nog altijd niet in het true gedeelte van de if

[ Voor 7% gewijzigd door Damic op 06-06-2017 21:15 ]

[Woy]

Damic schreef op dinsdag 6 juni 2017 @ 21:14:
Maarja dan kom ik nog altijd niet in het true gedeelte van de if

Dat kan 2 dingen betekenen.
1. Je roept die functie aan op de UI thread ( en dus niet binnen de DoWork callback van de BackgroundWorker. 2. Je maakt het control niet aan op de UI thread.

[Damic]

Jaja dat heb je al geschreven
1. de sub word aangeroepen via ui en dowork dus beide.
2de vind ik nogal raar want staat op een form die ik via een vast menu open

Juist even het programma opgestart en ik zien al 2 threads, main thread en een noname thread (dat zal de bgw wel zijn).

dit is de sub die het log venster toont.

Visual Basic .NET:

    Private Sub mnuLog_Click(sender As Object, e As EventArgs) Handles mnuLog.Click
        If Not bShowLog Then
            frmLog.Show()
            load_lng(frmLog.Name)
        End If
        frmLog.Focus()
    End Sub

[ Voor 33% gewijzigd door Damic op 06-06-2017 21:39 ]

[farlane]

Haal nou eens al die code uit je RefreshLog weg, en vervang het door enkel een

Visual Basic:

Sub RefreshLog()
    If InvokeRequired Then
        Invoke( new Action( RefreshLog ) )
    Else
        listView.AddItem( "Test" )
    End If
End Sub

Bij mij werkt dat prima:
1 Als direct aangeroepen
2 Vanuit een Thread handler
3 Vanuit een BackGroundWorker.DoWork
4 Vanuit een BackGroundWorker.ProgressReported callback

Waarbij 2 en 3 een andere thread zijn en dus via de Invoke gaan.

[whoami]

Damic schreef op dinsdag 6 juni 2017 @ 00:29:
@Anoniem: 917165 je hebt daar gelijk in maar dat doen ik niet.

Ik heb eventjes wat verder gelezen en blijkbaar is dat het standaard gedrag bij de backgroundworker, als je een call wil doen naar buiten de thread van de bgw moet je ReportProgress(integer,object) aanroepen en kom je terecht in ProgressChanged(). dat is wel heel veilig

Hoezo is dat niet veilig ?
De backgroundworker voert zaken uit op een andere thread en je blijft binnen die thread. Heb je vanuit die thread iets te melden, dan moet je er voor zorgen dat de ProgressChanged event geraised wordt.
Dat doe je dmv die ReportProgress method aan te roepen.

Jouw UI (main thread) kan subscriben op die ProgressChanged event.
Ik geloof dat de BackGroundWorker er zelf voor zorgt dat de eventhandler op die ProgressChanged event echter op de correcte thread (in dit geval UI thread) uitgevoerd wordt. Maw, de BackgroundWorker zal zelf zorgen dat de eventhandler ge-invoked wordt op de juiste thread. Vandaar dat je in die ProgressChanged eventHandler zelf een false terugkrijgt als resultaat op de call naar InvokeRequired.

Ik vermoed dat die ReportProgress method van de BackgroundWorker er ongeveer zo zal uit zien:

code:

public void ReportProgress()
{
    var handler = ProgressChanged;

    if( handler != null )
    {
          var x = handler.Target as ISynchronizeInvoke;

          if( x != null && x.InvokeRequired )
          {
               x.Invoke(handler, new [] {this, new ProgressChangedEventArgs()});
          }
          else
          {
                handler(this, new ProgressChangedEventArgs());
          }
    }
}

_{even uit de losse pols, dus dit compiled zeker niet maar 't is maar voor het idee}

Zorg ervoor dat je in uw BackgroundWorker enkel die taak uitvoert die long running is en ga van daaruit nergens rechtstreeks naar de UI. Indien je de UI wil updaten zal je dat doen dmv eventhandlers te subscriben op de events die de BackgroundWorker daarvoor beschikbaar stelt. (ProgressChanged & RunWorkerCompleted)

[ Voor 33% gewijzigd door whoami op 07-06-2017 11:16 ]

[Damic]

Werkt niet, thread of direct gaat maar bgw doet het niet.

Ik test dit in een 2de project waar amper iets in staat.
Form1, met 3 knoppen en een bgw

Visual Basic .NET:

Imports System.Threading
Public Class Form1
    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        Form2.Show()
    End Sub

    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        Form2.RefreshLog()
    End Sub

    Private Sub SetTextSafeBtn_Click(ByVal sender As Object, ByVal e As EventArgs) Handles setTextSafeBtn.Click
        Dim demoThread As Thread = New Thread(New ThreadStart(AddressOf Form2.RefreshLog)) With {.Name = "demothread"}
        demoThread.Start()
    End Sub

    Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
        If Not BackgroundWorker1.IsBusy Then BackgroundWorker1.RunWorkerAsync()
    End Sub

    Private Sub BackgroundWorker1_DoWork(sender As Object, e As System.ComponentModel.DoWorkEventArgs) Handles BackgroundWorker1.DoWork
        Form2.RefreshLog()
    End Sub
end class

Form2, alleen een listbox

Visual Basic .NET:

Public Class Form2
    Private Sub Form2_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        ListBox1.Items.Clear()
    End Sub

    Sub RefreshLog()
        If InvokeRequired Then
            Invoke(New Action(Sub() RefreshLog()))
        Else
            ListBox1.Items.Add("Test")
        End If
    End Sub
End Class

[farlane]

Dude, je maakt dezelfde fout als bij je memory probleem : je Form2 instanties zijn niet dezelfde als je het op deze manier doet.

Visual Basic:

Public Class Form1
    Private listViewForm As Form2


    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        listViewForm.AddListItem()
    End Sub

    Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click

        Dim thread As New Thread(AddressOf Callback)
        thread.Start()

    End Sub

    Private Sub Callback()
        listViewForm.AddListItem()
    End Sub

    Private Sub BackgroundWorker1_DoWork(sender As Object, e As System.ComponentModel.DoWorkEventArgs) Handles BackgroundWorker1.DoWork

        While True
            Thread.Sleep(1000)
            BackgroundWorker1.ReportProgress(0)
        End While
    End Sub

    Private Sub BackgroundWorker1_ProgressChanged(sender As Object, e As System.ComponentModel.ProgressChangedEventArgs) Handles BackgroundWorker1.ProgressChanged
        listViewForm.AddListItem()
    End Sub

    Private Sub Button3_Click(sender As Object, e As EventArgs) Handles Button3.Click
        BackgroundWorker1.RunWorkerAsync()
    End Sub

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        listViewForm = New Form2()
        listViewForm.Show()

    End Sub
End Class

Public Class Form2
    Public Sub AddListItem()
        If InvokeRequired Then
            Invoke(New Action(AddressOf AddListItem))
        Else
            ListView1.Items.Add("Test")
        End If
    End Sub
End Class

[ Voor 54% gewijzigd door farlane op 07-06-2017 12:21 ]

[whoami]

Het is gewoon conceptueel fout.

Je moet geen log updaten via een andere thread of een backgroundworker. Een backgroundworker/worker-thread moet werk verzetten; een blocking task/long running task uitvoeren.
Tijdens dat werk of na dat werk kan je gaan signallen aan 'viewers' dat er iets moet gebeuren; in jouw geval bv dat de ListBox die de logs weergeeft moet ververst worden met de gegeven resultaten).

[farlane]

whoami schreef op woensdag 7 juni 2017 @ 12:16:
Het is gewoon conceptueel fout.

Je moet geen log updaten via een andere thread of een backgroundworker. Een backgroundworker/worker-thread moet werk verzetten; een blocking task/long running task uitvoeren.
Tijdens dat werk of na dat werk kan je gaan signallen aan 'viewers' dat er iets moet gebeuren; in jouw geval bv dat de ListBox die de logs weergeeft moet ververst worden met de gegeven resultaten).

Ik daag u uit om dat de TS aan het verstand te prutsen

[Damic]

@farlane hazooo, ja dat werk en welk verstand
@whoami Hu?

[farlane]

Damic schreef op woensdag 7 juni 2017 @ 12:24:
@farlane hazooo, ja dat werk en welk verstand

Ja en begrijp je nu ook wat het probleem was dan?

@whoami Hu?

@whoami Nuff said

[whoami]

farlane schreef op woensdag 7 juni 2017 @ 12:23:
[...]

Ik daag u uit om dat de TS aan het verstand te prutsen

Challenge accepted!

Damic:

Refactor jouw RefreshLog method zodanig dat daar geen enkele afhankelijkheid meer inzit naar om het even wat in jouw UI (seperation of concerns).
Begin misschien met het hernoemen van die method, zodanig dat de naam reflecteert wat die method in principe moet doen.

Eens die method gedaan heeft wat ze moet doen, kan je de resultaten van dat werk gaan 'rapporteren' naar de 'Viewers' die hierin geinteresseerd zijn: ttz, de Form of UI controls die deze gegevens willen tonen.
Dit doe je dmv een eventhandler op een Event dat de BackgroundWorker beschikbaar stelt. In die eventhandler ga je dan die gegeven data gaan tonen (gaan laden in die ListBox of ListView).

Op die manier heb je een scheiding tussen de UI en de uiteindelijke taak die je uitvoert. Je hebt dan geen afhankelijkheid naar specifieke UI elementen in jouw BGW en kan dus in principe meerdere 'viewers' gaan hebben voor die ene taak.
/in-een-notedop.

[Damic]

@farlane ja dat begrijp ik nu, blijkbaar word een 2de/3de... form niet op de main thread geopend, maar nu zit ik wel met een ander probleem. Main form word niet meer getoond, als ik geluk heb dan heb ik nog wel preview in de taakbalk maar daar blijft het bij.

@whoami Refreshlog doet wat het moet doen, misschien kan ik het wel hernoemen hernoemd naar UpdateLogView() maar dat doet het ook, veel minder code of in stukken trekken is belachelijk.

Als ik naar het logboek schrijf doen ik dat via de Add2Log() functie en op het einde staat daar if LogForm isnot nothing then LogFrom.UpdatelogView()

[whoami]

Damic schreef op woensdag 7 juni 2017 @ 13:29:


@whoami Refreshlog doet wat het moet doen, misschien kan ik het wel hernoemen hernoemd naar UpdateLogView() maar dat doet het ook, veel minder code of in stukken trekken is belachelijk.

Nee, het doet te veel. Je haalt en gegevens op, en je gaat je ListView gaan populaten.
Als je vind dat je het niet verder uit elkaar moet trekken, dan is het voor zover ik het zie ook niet nuttig om het uit te voeren in een aparte thread. Aangezien je in die code UI elementen gaat aanspreken, moet je dat doen op de UI thread. Er moet dus een context-switch gebeuren om die code correct uit te voeren. Dat wil dan ook zeggen dat de code die naar de DB gaat ook op de UI thread zal uitgevoerd worden.

[farlane]

Damic schreef op woensdag 7 juni 2017 @ 13:29:
@farlane ja dat begrijp ik nu, blijkbaar word een 2de/3de... form niet op de main thread geopend

Dat is niet eens in de buurt van wat de oorzaak van je probleem is (afgezien van de architectuur die niet klopt)

TIP: Verander in mijn voorbeeld maar eens alle referenties naar listViewForm naar Form2 en zet een breakpoint in de constructor van Form2

@whoami Refreshlog doet wat het moet doen, misschien kan ik het wel hernoemen hernoemd naar UpdateLogView() maar dat doet het ook, veel minder code of in stukken trekken is belachelijk.

@whoami Je gaat het niet redden ben ik bang. De TS heeft al meerdere malen laten zien dat hij geen advies aanneemt over dit soort belangrijke dingen.

[Damic]

Wat moet ik anders doen met de gegevens die ik juist heb opgehaald? In een lijst steken en dan via een andere sub die lijst uitlezen?

Nee de bedoeling is dat waar de code ook is in welke thread dan ook, zodra er iets word toegevoegd aan het logboek en het logboek venster open staat dat die lijst word aangevuld.

Belangrijke dingen, dat is eind van de maand je pree krijgen en je betalingen kunnen doen en mijn dagelijkse job is NIET programmeren

[whoami]

Damic schreef op woensdag 7 juni 2017 @ 14:37:
Wat moet ik anders doen met de gegevens die ik juist heb opgehaald? In een lijst steken en dan via een andere sub die lijst uitlezen?

Nee de bedoeling is dat waar de code ook is in welke thread dan ook, zodra er iets word toegevoegd aan het logboek en het logboek venster open staat dat die lijst word aangevuld.

Je gaat toch niet iedere keer dat je uw 'log' refresht de hele listview gaan clearen en alles opnieuw ophalen hoop ik ?

Belangrijke dingen, dat is eind van de maand je pree krijgen en je betalingen kunnen doen en mijn dagelijkse job is NIET programmeren

Je hebt gelijk. Ik doe dan ook beter verder met waarvoor ik betaal krijg ipv hier nog verder energie in te stoppen.

[Damic]

Nee ik hou bij wat de laatste id was en dan doe ik een add.

[ Voor 6% gewijzigd door Damic op 07-06-2017 14:54 ]

[whoami]

Het is gewoon onmogelijk om in een worker-thread je data te gaan ophalen, en in diezelfde worker-thread (die niet je UI thread is), je UI gaan manipuleren.
Ik hoop dat je het hiermee eens bent.

Als ik nog eens die code bekijk, dan vind ik het trouwens overkill om op die locatie met een worker-thread te gaan werken.
Wat is dat dbLog object ? Je zou ervoor kunnen kiezen om op die class een GetDataAsync method te maken je data asynchroon ophaalt.
Zo iets (in C#)

C#:

public class MyDbClass
{
    public Task<DataTable> GetDataAsync( string sql )
    {
           // Ik weet niet hoe je hier je data ophaalt, wellicht met een data-adapter ?
           // deze heeft geen async methods, dus zal je hier zelf een task moeten starten
           return Task.Run<DataTable>(() =>
            {
                SqlCommand cmd = new SqlCommand("...");
                SqlDataAdapter da = new SqlDataAdapter();
                da = new SqlDataAdapter(cmd);
                DataTable dt = new DataTable();
                da.Fill(dt);
                return dt;
            });


          // Indien je met een datareader werkt om de data op te halen, kan je de ExecuteReaderAsync
          // method gebruiken:
          using( var reader = await dataCommand.ExecuteReaderAsync())
          {
               // fill and return datatable.
          }

    }
}

Deze method roep je op in jouw applicatie en met het resultaat daarvan ga je jouw listview gaan updaten. Je kan dan het gebruik van een thread of BackgroundWorker in je WinForms applicatie gaan schrappen.

Je kan deze method dan als volgt gaan gebruiken:

code:

var dt = await dbLog.GetDataAsync(".....");

[farlane]

Damic schreef op woensdag 7 juni 2017 @ 14:37:
Belangrijke dingen, dat is eind van de maand je pree krijgen en je betalingen kunnen doen en mijn dagelijkse job is NIET programmeren

[Damic]

Wat ?

@whoami bedankt voor de moeite maar ik snap het toch niet.

[whoami]

Dan heb ik misschien een interessante link voor je

[farlane]

Damic schreef op woensdag 7 juni 2017 @ 15:41:
Wat ?

De blatante desinteresse om fatsoenlijk werk af te leveren, dat.

[Damic]

Dat doet productie wel hier zijn de tekeningen trek je plan