[VB] "Dim withevents myobj as object" werkt niet

[robbertb]

Ik heb een probleem, ik had eerst events ontvangen goed werke met:

Visual Basic:

dim withevents MyObj as clsMydll

Dat werkt, maar nu wil ik ee andere structuur, een algemeen object om daar objecten in te laden onder runtime, dus niet meer met references te werken.
Daarvoor kan ik doen:

Visual Basic:

Dim MyObj As Object
Set MyObj = CreateObject("mydll.clsMydll")

Maar ik wil ook events van de DLL ontvangen. Echter onderstaade declaratie kan niet:

Visual Basic:

Dim WithEvents MyObj As Object

Iemand en oplossing?

[Tukk]

Uit mijn blote bol:

VB weet niet of je dit object wel met events MAG declareren. Ik neem aan dat VB je een
compilatie foutmelding geeft bij de regel waarin 'withevents' staat?

Wat gebeurd er als je toch een event programmeerd op het object?

dus zoiets als

Visual Basic:

sub MyObj_Event
  msgbox "test"
end sub

Krijg je dan het event te zien?

[robbertb]

Tukk schreef op 25 March 2003 @ 14:36:
Uit mijn blote bol:

VB weet niet of je dit object wel met events MAG declareren. Ik neem aan dat VB je een
compilatie foutmelding geeft bij de regel waarin 'withevents' staat?

Wat gebeurd er als je toch een event programmeerd op het object?

dus zoiets als

Visual Basic:

sub MyObj_Event
  msgbox "test"
end sub

Krijg je dan het event te zien?

Mja klinkt wel logisch wat je zegt.
Maar hij stopt idd bij die regel bij het compileren en geeft de melding:
Compile error:
Expected identifier

Maar lijkt me niet dat het zonder die toevoeging "withevents" kan werken, als dat zo is, waarom bestaat die toevoeging dan..

Edit: net geprobeerd, en nu is me event stuk dus dat werkt niet

[ Voor 8% gewijzigd door robbertb op 25-03-2003 14:43 ]

[Tukk]

Maar lijkt me niet dat het zonder die toevoeging "withevents" kan werken, als dat zo is, waarom bestaat die toevoeging dan..

Tja, dat klinkt best logsich wat je daar zegt.
IMHO gaat het je niet lukken. Ik zou bijna zeggen ga naar VB.Net,
maar dat is dan ook weer met een Patriot op zandkorrel schieten

[robbertb]

Tukk schreef op 25 March 2003 @ 15:10:
[...]


Tja, dat klinkt best logsich wat je daar zegt.
IMHO gaat het je niet lukken. Ik zou bijna zeggen ga naar VB.Net,
maar dat is dan ook weer met een Patriot op zandkorrel schieten

mja das geen optie nu, we werken hier nog met VB.. wij waren er ook allang uit dat we beter ee andere programmeertaal kunnen gebruiken..
Of we moete ee andere oplossing zien te vinden voor de events, maar dat wordt er niet overzichtelijker va denk ik...

Maar wat ik wil kan dus niet?

[Twee Dee]

Waarom wil je eigenlijk heb object declareren als "object" en niet als clsmydll.

Het is zo veel handiger debuggen, en als je het als Object declareert dan werkt de intellisense ook niet (de tab-completion).

Waarom zou je één object willen om afwisselend verschillende objecten in te laden? "Netjes programmeren" is het niet, en ook voor de overzichtelijkheid is het denk ik niet bevorderlijk.

[robbertb]

Twee Dee schreef op 25 March 2003 @ 15:24:
Waarom wil je eigenlijk heb object declareren als "object" en niet als clsmydll.

Het is zo veel handiger debuggen, en als je het als Object declareert dan werkt de intellisense ook niet (de tab-completion).

Waarom zou je één object willen om afwisselend verschillende objecten in te laden? "Netjes programmeren" is het niet, en ook voor de overzichtelijkheid is het denk ik niet bevorderlijk.

Ik vind het juist overzichtelijk eigenlijk. Omdat er altijd maar 1 object actief kan zijn in mijn opzet.. wil soort van MDI nabootse maar er mag dan maar 1 venster in staan en nooit meer. ANders moet eerst worden bijgehouden wel object geladen is, zodat die weer gesloten kan worden. Als er gewoo een algemeen object wordt gebruikt hoeft dat niet. Daarnaast wil ik de dlls pas laden op moment dat ze nodig zijn, dus niet bij reference in vb zelf va te voren al definieren.
Daarnaast moet alles volledig onafhankelijk zijn.

[ Voor 4% gewijzigd door robbertb op 25-03-2003 15:49 ]

[Tukk]

robbertb schreef op 25 March 2003 @ 15:47:
[...]
Ik vind het juist overzichtelijk eigenlijk. Omdat er altijd maar 1 object actief kan zijn in mijn opzet.. wil soort van MDI nabootse maar er mag dan maar 1 venster in staan en nooit meer. ANders moet eerst worden bijgehouden wel object geladen is, zodat die weer gesloten kan worden. Als er gewoon een algemeen object wordt gebruikt hoeft dat niet. Daarnaast wil ik de dlls pas laden op moment dat ze nodig zijn, dus niet bij reference in vb zelf va te voren al definieren.

Dat is ook wel programmatorisch mooi te maken. Je referenced alleen naar DLL's als je ze met early binding declareerd.

Je gaat problemen krijg met je object als je events op dat MDI_object gebruikt en het volgende MDI_object weer geen events bevat. VB zal de interface gaan missen en errors geven.

robbertb schreef op 25 March 2003 @ 15:47:
Daarnaast moet alles volledig onafhankelijk zijn.

Onafhankelijk van wat? Van de versie van de DLL? Dat kan met early binding.
Of de DLL er wel is? Dat kan met early binding.

[robbertb]

Tukk schreef op 25 March 2003 @ 15:58:
[...]

Dat is ook wel programmatorisch mooi te maken. Je referenced alleen naar DLL's als je ze met early binding declareerd.

Je gaat problemen krijg met je object als je events op dat MDI_object gebruikt en het volgende MDI_object weer geen events bevat. VB zal de interface gaan missen en errors geven.

[...]

Onafhankelijk van wat? Van de versie van de DLL? Dat kan met early binding.
Of de DLL er wel is? Dat kan met early binding.

Ik wil juist geen early binding..
En het is geen MDI... ik laad me dlls in een container (picturebox)

[Twee Dee]

Ben je bekend met het programmeren tegen interfaces?

Zoals het mij overkomt lijkt me dit precies wat je nodig hebt. Je definieert een interface en hebt alleen een referentie nodig naar de interface.
Vervolgens kun je zoveel dll's ontwerpen die je wilt, waarbij je de interface implementeert.
Je kunt nu je object vullen met welk object dan ook dat de interface geimplementeerd heeft, en het werkt nog netjes ook!

Op deze manier kun je namelijk ook met events werken, en toch het object geschikt houden voor verschillende dll's.

[robbertb]

Twee Dee schreef op 25 maart 2003 @ 16:09:
Ben je bekend met het programmeren tegen interfaces?

Zoals het mij overkomt lijkt me dit precies wat je nodig hebt. Je definieert een interface en hebt alleen een referentie nodig naar de interface.
Vervolgens kun je zoveel dll's ontwerpen die je wilt, waarbij je de interface implementeert.
Je kunt nu je object vullen met welk object dan ook dat de interface geimplementeerd heeft, en het werkt nog netjes ook!

Op deze manier kun je namelijk ook met events werken, en toch het object geschikt houden voor verschillende dll's.

Nee daar ben ik niet bekend mee (geloof ik).. maar wat je zegt is wel wat ik nodig heb.. Maar hoe gaat dat in zn werk, is de implementatie daarvan wezelijk anders ?

[ Voor 3% gewijzigd door robbertb op 25-03-2003 16:52 ]

[Verwijderd]

Met het Implements statement. Voor methodes en properties werkt dat, maar ik vrees dat het niet werkt met events... Maar je zou eens kunnen kijken.

[Crazy D]

robbertb schreef op 25 March 2003 @ 16:50:
Nee daar ben ik niet bekend mee (geloof ik).. maar wat je zegt is wel wat ik nodig heb.. Maar hoe gaat dat in zn werk, is de implementatie daarvan wezelijk anders ?

Type "Implements" en ram op F1 Er zit in MSDN een example bij die het volgens mij wel vrij duidelijk maakt (zeker als je 'm ff door-debugt).

Maar met een event krijg ik het ook niet voor elkaar, ik kom niet verder dan "Object or class does not support the set of events". Op MSDN hebben ze het ook alleen maar over methods (en een property is in feite ook een method), over events houden ze wijzelijk hun mond
Ik heb het trouwens geprobeert door in een interface-class een event neer te zetten, maar die staat daar uit z'n neus te eten

Je zou het ook "andersom" kunnen doen, een interface-class maken en die gebruiken in je form, en alle classes die nu een event raisen die de form afvangt, het via die interface kunnen laten doen, maar ik denk dat je het dan eigenlijk alleen maar omslachtiger maakt Maar dan hoef je iig geen events meer af te vangen die door de class worden geraised, is "withevents" dus niet nodig, en zou het wel met een Object kunnen.

[Verwijderd]

Dim withevents MyObj as New clsMydll

of

Dim MyObj As Object
Set MyObj = New CreateObject("mydll.clsMydll")

[robbertb]

Mja als ik dat zo hoor heb ik dus ook niet zo veel aan implements als ik daar een probleem blijf houden met de events. Wat raar dat hier zo geen oplossing voor is

Verwijderd schreef op 25 March 2003 @ 20:06:
Dim withevents MyObj as New clsMydll

of

Dim MyObj As Object
Set MyObj = New CreateObject("mydll.clsMydll")

Mja dus met events of anders zonder events. zo ver was ik ook

[robbertb]

Iemand nog een idee of zijn er nog andere manieren om events op te vangen of een andere aanpak hoe ik mijn applicatie het beste zou kunnen bouwen?
Want om nou steeds een lusje te late lopen of een variabele is geset, vind ik ook zo slordig en onprofessioneel. Daarvoor was withevents juist zo mooi.

Of een andere manier van DLLS instellen, de mogelijkheden die ik tot nu toe weet zijn:

-Als reference instellen.
Nadeel: alle dlls worden gelijk al ingesteld, dit kost veel tijd bij opstarten van je programma bij veel dlls

-als CreateObject("mydll.class1")
Nadeel: withevents kan niet meer worden gebruikt

[ Voor 16% gewijzigd door robbertb op 27-03-2003 00:21 ]

[Gerco]

Wat je kunt doen is het volgende:

Visual Basic .NET:

Dim objMyDLL As IEventSource
Dim withevents objEventRelay As EventRelay

Set objMyDLL = CreateObject("MyDLL.clsMyDLL")
objMyDLL.SetEventRelay objEventRelay

De EventRelay class bevat dan methodes waarin hij Events fired, voorbeeld:

Visual Basic .NET:

Event CancelClicked()

Public Sub RaiseCancelClicked()
  RaiseEvent Cancel_Clicked
End Sub

En de interface IEventSource is als volgt:

Visual Basic .NET:

Public Sub SetEventRelay(Relay As EventRelay)
End Sub

Dan kun je in je DLL het volgende doen:

Visual Basic .NET:

Implements IEventSource

Private evrRelay As EventRelay

Public Sub EventSource_SetEventRelay(RHS As EventRelay)
  Set evrEventRelay = EventRelay
End Sub

Public Sub SomeSub()
  evrRelay.RaiseCancelClicked
End Sub

En je events worden prima doorgegeven aan je hoofdprogramma, Je kan zelfs meerdere EventSources maken en daarvan allemaal events tegelijk ontvangen als je wilt, maar dat is in jouw geval niet nodig. Je moet gewoon voor iedere event die je wilt doorgeven een methode en een event in de EventRelay aanmaken en presto.

DISCLAIMER: Uit het blote koppie getikt, ik heb geen idee of het uberhaupt wel compiled

[ Voor 5% gewijzigd door Gerco op 27-03-2003 07:25 ]

[robbertb]

Gerco schreef op 27 March 2003 @ 07:24:
Wat je kunt doen is het volgende:
[...]
En je events worden prima doorgegeven aan je hoofdprogramma, Je kan zelfs meerdere EventSources maken en daarvan allemaal events tegelijk ontvangen als je wilt, maar dat is in jouw geval niet nodig. Je moet gewoon voor iedere event die je wilt doorgeven een methode en een event in de EventRelay aanmaken en presto.
DISCLAIMER: Uit het blote koppie getikt, ik heb geen idee of het uberhaupt wel compiled

Klinkt opzich wel handig maar kan het niet efficienter? Zo krijg je wel snel een complexe onoverzichtelijkere structuur.. En de boel wordt zo wel afhankelijker omdat je dus alle events erin moet zetten.

Visual Basic:

Public Sub SetEventRelay(Relay As EventRelay)
End Sub

Moet hier nieti nog meer bij? de functie doet niks? En hier komt ook nooit iets bij? Kan deze niet worden samengevoegd met een andere module?

Ik heb het geprobeerd te maken maar krijg een fout bij "Implements IEventSource":
Compile error: Object Module needs to implement 'SetEventRelay' for interface 'IEventSource'

[ Voor 3% gewijzigd door robbertb op 27-03-2003 09:46 ]

[Verwijderd]

Je zou ook ff naar http://support.microsoft.com/default.aspx?scid=kb;NL;q190670 kunnen kijken. Ik weet niet of dat ook met objecten werkt, maar op deze manier kan je in ieder geval dynamisch componenten aanmaken en ook hun events afvangen zonder dat je weet welke events mogelijk zijn...
Maar ik weet dus niet of dit ook voor objecten op gaat...

Dat idee van Gerco is anders ook een oplossing, zoiets heb ik ook zelf al eens toegepast, maar dat is denk ik iets meer werk...

[robbertb]

Verwijderd schreef op 27 March 2003 @ 09:49:
Je zou ook ff naar http://support.microsoft.com/default.aspx?scid=kb;NL;q190670 kunnen kijken. Ik weet niet of dat ook met objecten werkt, maar op deze manier kan je in ieder geval dynamisch componenten aanmaken en ook hun events afvangen zonder dat je weet welke events mogelijk zijn...
Maar ik weet dus niet of dit ook voor objecten op gaat...

Dat idee van Gerco is anders ook een oplossing, zoiets heb ik ook zelf al eens toegepast, maar dat is denk ik iets meer werk...

Dat werkt dus niet met objecten, omdat vb nog niet weet wat voor events erin zitten.. ik wil dus met create object en geen reference

[Tukk]

[b]Gerco schreef op 27 March 2003 @ 07:24
<KNIP prop="lang verhaal, staat hier boven">

Jammer, dat je niet '+4 behulpzaam' kan geven in GOT...

[Verwijderd]

robbertb schreef op 27 March 2003 @ 10:00:
[...]

Dat werkt dus niet met objecten, omdat vb nog niet weet wat voor events erin zitten.. ik wil dus met create object en geen reference

Het mooie hiervan is dat het dus WEL werkt zonder dat je een reference hoeft te hebben. Dit gebruik ik zelf om een bepaald component te gebruiken als dat geinstalleerd is, maar als het niet geinstalleerd is, dan kan het programma gewoon verder...
Maar goed, voor objecten weet ik niet of het werkt, maar het zou zomaar kunnen...

[robbertb]

Tukk schreef op 27 March 2003 @ 10:09:
[...]


Jammer, dat je niet '+4 behulpzaam' kan geven in GOT...

Jup was wel handig zo heel uitgewerkt verhaal heeft wel ff tijd gekost
Maar het werkt dus niet echt.. en vraag me af of er een betere methode is.. Ik was net op me com+ server bezig e zag dat ik ook event classes kon installere misschien dat ik daar iets mee kan ofzo. Maar denk het niet, gaat om de declaratie binnen vb met CreateObject.

Verwijderd schreef op 27 March 2003 @ 10:30:
[...]

Het mooie hiervan is dat het dus WEL werkt zonder dat je een reference hoeft te hebben. Dit gebruik ik zelf om een bepaald component te gebruiken als dat geinstalleerd is, maar als het niet geinstalleerd is, dan kan het programma gewoon verder...
Maar goed, voor objecten weet ik niet of het werkt, maar het zou zomaar kunnen...

Nou zoiets had ik dus al geprobeert, maar Object staat dan niet in het rijtje, en als je dat toch doet krijg je een foutmelding

[Tukk]

Je probleem is de grenzen van VB/COM. Heb je al aan andere technieken gedacht?
Bijvoorbeeld dat je DLL's UDP/IP messages stuurt naar je eigen applicatie?

[Gerco]

robbertb schreef op 27 March 2003 @ 09:45:
Klinkt opzich wel handig maar kan het niet efficienter?

Niet als je puur VB wilt blijven gebruiken, je zou natuurlijk altijd dingen als window messages, pipes, en dergelijke technieken kunnen gebruiken, maar da's een stuk ingewikkelder.

Zo krijg je wel snel een complexe onoverzichtelijkere structuur.. En de boel wordt zo wel afhankelijker omdat je dus alle events erin moet zetten.

Da's altijd 1 van mijn grote bezwaren tegen VB geweest, als je je programma wilt opzetten in "losse" componenten wordt het heel moeilijk een beetje onafhankelijk te houden.

Moet hier nieti nog meer bij? de functie doet niks? En hier komt ook nooit iets bij? Kan deze niet worden samengevoegd met een andere module?

Nee, het is een interface, die methode daar betekent alleen dat in een class die die interface implementeert, er een methode aanwezig dient te zijn die dezelfde signature heeft als deze en hij moet <InterfaceNaam>_<MethodeNaam> heten.

Ik heb het geprobeerd te maken maar krijg een fout bij "Implements IEventSource":
Compile error: Object Module needs to implement 'SetEventRelay' for interface 'IEventSource'

Zie hierboven, de class waar Implements IEventSource instaat MOET de methode IEventSource_SetEventRelay bevatten. In de linker combobox boven je code window kun je de interface uitkiezen en VB zal zelf de methode signature invullen die nodig is. Je zal zelf de code erin moeten zetten.

Omdat VB geen inheritance ondersteund, moet je de code om de EventRelay te setten en te gebruiken in iedere class die de IEventSource interface implementeert opnemen, ik kan wel een voorbeeldje in elkaar smijten als je wilt, maar dat wordt dan pas vanavond.

Edit:
Ik had een typo gemaakt in de code hierboven, het moest dit zijn:

Visual Basic .NET:

Public Sub IEventSource_SetEventRelay(RHS As EventRelay)

Edit2
Het is natuurlijk niet NODIG om zo'n afhankelijke structuur te gebruiken, je kan je EventRelay ook zo proggen dat 'ie wat strings aanneemt en aan de hand daarvan wat events gaat raisen. Of je gebruikt 1 events waarna je met je parameters gaat bepalen wat er moet gebeuren en de bijhorende subs aanroepen. De eventrelay hoeft helemaal niet te weten welke events er uitgewisseld worden, zo lang er maar 1 "passthrough" event is.

[ Voor 25% gewijzigd door Gerco op 27-03-2003 12:53 ]

[robbertb]

naja heb zoiets gemaakt en aantal dingen aangepast, zoals bv cancel_clicked in cancelclicked omdat zo ook het event gedefinieerd was... en nog wat kleine dingen. maar krijg het niet aan de praat, na een en ander te debugen krijg ik geen foutmeldingen maar er gebeurd niks bij een event
Kan het niet simpeler of heel anders?
Iets anders voor create object, en iets anders dan een reference naar een dll maar andere manier?? Ik wil van die dll hell af Althans al die early referenties (zo heet dat toch, als je ze van te voren al vast legt, voor runtime al set?) maakt het programma zo traag omdat al die dlls geladen moet worden.. en ik wil alleen laden wat ik nodig heb... en zo min mogelijk steeds opnieuw moeteren registreren als ik een dll heb geregistreerd.. want worden steeds meer dlls die dan als child in een onderliggend niveau van een andere dll zit.. als programma dan heel uitgebreid wordt, blijf je aan het hercompilen en de referenties goed zetten..
En verder zit ik dan dus nog met die events... Wat is nu de beste manier om zo soort applicatie te maken mbv onafhankelijke modules in een 3lagen structuur

[ Voor 60% gewijzigd door robbertb op 27-03-2003 23:53 ]

[Gerco]

Als je de boel ECHT onafhankelijk wilt maken, kun je geen VB features gebruiken voor je communicatie, of je moet late binding gebruiken, wat je programma weer traag maakt.

Het zou leuk zijn als je gewoon een "echte" dll kon maken en die aanroepen uit je prog, op die manier zou je een echte plugin structuur kunnen maken, zonder al dat ge COM registreer e.d. Dat kan alleen niet om 2 redenen:
1. Je kan geen echte dll's maken, kun je omheen door de compile controller te gebruiken
2. Je moet vooraf declareren uit welke dll je functies komen (Declare Function blabla) en je kunt dus geen functie in een normale DLL aanroepen zonder van tevoren te weten welke dll het is. Daar kun je alleen omheen door in C(++) een dll te maken die dat werk voor je doet (of je gebruikt compile controller om een C(++) module in je programma te linken die dat doet)