[VB6] Opzetten van algemene applicatie instellingen

[Lorn]

Situatie
Ik ben een VB6 applicatie aan het ontwikkelen. Binnen deze applicatie moet de gebruiker een aantal instellingen kunnen doen, deze instellingen moeten nadat ze zijn toegepast direct door de applicatie gebruikt gaan worden.

Mijn standaard oplossing
Wat ik normaal doe is het maken van een class die de instellingen bijhoud. Per setting maak ik een property aan en bij het initialiseren van de class worden de waarden ingelezen uit een bestand /registry /database. Vervolgens maak ik meestal in een module een public property die door alle code in de applicatie wordt gebruikt om bij de class te komen. Een beetje het idee van een Singleton (als iemand een betere implementatie heeft dan hou ik me aanbevolen.

Het nadeel van deze methode is dat er na het afsluiten van het configuratiescherm moet worden nagelopen welke wijzigingen zijn gedaan en deze doorvoeren binnen de applicatie.

Het probleem
De bovenstaande oplossing is opzich ook wel toe te passen in mijn te bouwen applicatie maar graag zou ik een event willen sturen als een setting veranderd. Hiervoor had ik bedacht een event op te nemen in mijn Settings class die een ID verstuurd van de gewijzigde settings (Enum type) en de nieuwe waarde (Variant). Het event zou dan afgevuurd moeten worden zodra de Property Let /Set routine de nieuwe waarde heeft geaccepteerd. De applicatie zou dan alleen hoeven te reageren op de events en dat leek me wel een handige oplossing.

Het probleem is echter dat ik nu de class niet meer kan verstoppen achter mijn globaal toegankelijke property. Je kunt immers in VB6 alleen events afvangen in een Form of een Class en dus niet in de module die ik hier altijd voor gebruik. Opzich zou ik hier omheen kunnen werken door mijn settings class onder te brengen in het hoofdscherm en door te geven naar het configuratiescherm dat dan vervolgens de instellingen toont en laat bewerken. Alleen dan is het probleem hoe ik bij mijn settings kom vanuit een andere module.

De vraag
Hoe lossen mij mede Tweakers dit op? Op welke manier zorgen jullie dat de instellingen goed worden doorgevoerd door de hele applicatie en op welke manier wordt er voor gezorgd dat de toegang tot de settings goed is geregeld?

[sopsop]

't kan zijn dat ik je niet helemaal goed begrijp, maar je kunt toch gewoon bij het toepassen van je gewijzigde instellingen, die wegschrijven in zowel je database/bestand/registry als in je class. Wijzigingen zijn dan meteen doorgevoerd in je running app.

[Lorn]

boppert schreef op donderdag 01 december 2005 @ 12:13:
't kan zijn dat ik je niet helemaal goed begrijp, maar je kunt toch gewoon bij het toepassen van je gewijzigde instellingen, die wegschrijven in zowel je database/bestand/registry als in je class. Wijzigingen zijn dan meteen doorgevoerd in je running app.

Opzich heb je gelijk maar het gaat hier om dingen die uit of aan staan. Nadat de gebruiker de instellingen heeft gewijzigd moet er opnieuw gekeken worden of deze processen gestart dan wel gestopt moeten worden.

[ThunderNet]

Je zou in de klassen die zich opnieuw moeten initaliseren tijdens nieuwe instellingen.
een Refresh() functie aanmaken.
Als je dan elke klasse die gebruikt maakt van de settings-klasse toevoegd aan een object-array (in de settings klasse) kun je dmv een loopje in alle klasses in die array de Refresh functie aanroepen.

Of zou dit een verkeerde manier van werken zijn?

[Verwijderd]

ThunderNet schreef op donderdag 01 december 2005 @ 13:06:
Je zou in de klassen die zich opnieuw moeten initaliseren tijdens nieuwe instellingen.
een Refresh() functie aanmaken.
Als je dan elke klasse die gebruikt maakt van de settings-klasse toevoegd aan een object-array (in de settings klasse) kun je dmv een loopje in alle klasses in die array de Refresh functie aanroepen.

Of zou dit een verkeerde manier van werken zijn?

Zoiets heb ik ook ooit eens gemaakt, maar dan wat algemener. Een object ( form o.i.d ) kon zich registreren op een globaal messaging object. Daarbij werd opgegeven welke message, en welke functie moest wordn aangeroepen. Vanuit een ander opbject kon je dan via die messager een bericht sturen aan alle objecten die zich hadden "geabonneerd" op dat bericht.

Het nut hiervan was dat ik dus ( het was een handels applicatie ) het artikelscherm kon laten "broadcasten" dat er een record was veranderd, zodat eventuele andere schermen die ook artikelgegevens ( of delen ervan ) toonden, zich konden refreshen.

[ThunderNet]

Hele nette uitvoering en bewoording van wat ik bedoelde
Lijkt me dat zo'n systeem heel bruikbaar is in deze situatie.

[zwippie]

Om het googlen wat makkelijker te maken; wat ThunderNet en FFrenzy bedoelen heet volgens mij een EventDispatcher (in Java in ieder geval).

[Lorn]

Verwijderd schreef op donderdag 01 december 2005 @ 13:13:
[...]

Zoiets heb ik ook ooit eens gemaakt, maar dan wat algemener. Een object ( form o.i.d ) kon zich registreren op een globaal messaging object. Daarbij werd opgegeven welke message, en welke functie moest wordn aangeroepen. Vanuit een ander opbject kon je dan via die messager een bericht sturen aan alle objecten die zich hadden "geabonneerd" op dat bericht.

Het nut hiervan was dat ik dus ( het was een handels applicatie ) het artikelscherm kon laten "broadcasten" dat er een record was veranderd, zodat eventuele andere schermen die ook artikelgegevens ( of delen ervan ) toonden, zich konden refreshen.

OK, dit klinkt wel interessant. Op welke manier verstuurde je dan dat bericht naar de objecten die hadden aangegeven op de hoogte te willen blijven? Een eigen Windows message?

Ik zal ook eens opzoek gaan naar die EventDispatcher, bedankt voor de tip!

[ Voor 6% gewijzigd door Lorn op 01-12-2005 13:53 ]

[jelmervos]

Is dat niet gewoon het Observer design pattern?

[Verwijderd]

Lorn schreef op donderdag 01 december 2005 @ 13:53:
[...]


OK, dit klinkt wel interessant. Op welke manier verstuurde je dan dat bericht naar de objecten die hadden aangegeven op de hoogte te willen blijven? Een eigen Windows message?

Ik zal ook eens opzoek gaan naar die EventDispatcher, bedankt voor de tip!

Eigen Windows messages implementeren in VB6 is niet zo makkelijk. de benodigde subclassing maakt debuggen namelijk erg moeilijk.

Ik hield in een globale class een custom collection bij met daarin per entry een referentie naar het object, de message ( als string ), en de functie ( ook als string ).
de desbetreffende functie kun je aanroepen met CalByName.

[Lorn]

Verwijderd schreef op donderdag 01 december 2005 @ 14:37:
[...]

Eigen Windows messages implementeren in VB6 is niet zo makkelijk. de benodigde subclassing maakt debuggen namelijk erg moeilijk.

Ik hield in een globale class een custom collection bij met daarin per entry een referentie naar het object, de message ( als string ), en de functie ( ook als string ).
de desbetreffende functie kun je aanroepen met CalByName.

De omschrijving doet me een beetje denken aan een Callback functie, klopt dat? Je hebt inderdaad gelijk dat custom Windows messages een probleem zijn in VB6, daar wordt je niet heel vrolijk van.

Ik heb ondertussen nog wat gezocht naar beschrijving van een EventDispatcher maar nog niks gevonden waar ik echt enthousiast van kon worden. Nog geen tijd gehad om te kijken naar het Observer design pattern, dit hoop ik vrijdag te kunnen doen.

[Verwijderd]

Lorn schreef op donderdag 01 december 2005 @ 21:52:
[...]


De omschrijving doet me een beetje denken aan een Callback functie, klopt dat? Je hebt inderdaad gelijk dat custom Windows messages een probleem zijn in VB6, daar wordt je niet heel vrolijk van.

Ik heb ondertussen nog wat gezocht naar beschrijving van een EventDispatcher maar nog niks gevonden waar ik echt enthousiast van kon worden. Nog geen tijd gehad om te kijken naar het Observer design pattern, dit hoop ik vrijdag te kunnen doen.

Ik zal morgen wel eens kijken of ik de code die wij hier nu gebruiken kan posten.....zal wat namen moeten veranderen misschien. Ik beloof je echter niets !