[vb.net] variabele zoeken

[Verwijderd]

Ik ben bezig met een productconfigurator te schrijven die bij bepaalde samenstellingen bepaalde waardes moet wegschrijven naar autodesk inventor.

Het is zo opgebouwd dat in inventor bepaalde parameters staan die worden gevoed met gegevens die ik opgeef in mn applicatie. Alleen is niet voor elke samenstelling hetzelfde aantal parameters nodig. Dit verschilt nogal.

Nu heb ik in een database de parameternaam van inventor gezet en de waarde die moet worden gevoed naar inventor. Deze waarde staat alleen niet als de echte waarde in de database maar als de variabele naam die ik in de applicatie gebruik.

Waar ik dus graag achter zou komen is of het mogelijk is een variable in mn applicatie te zoeken (aan de hand van de naam die ik uit mn database trek) en deze waarde door te spelen naar inventor.

Bijvoorbeeld :
Ik heb in mn applicatie een waarde opleg_lengte als integer aangemaakt. Hier staan een aantal milimeters ingevuld. Nu heb ik in mn database de naam opleg_lengte staan die ik door wil sturen. Maar dan niet opleg_lengte maar de waarde die er op dat moment aanhang.
Met controls is het me wel gelukt dus ik gok dat het met variabelen ook wel mogelijk moet zijn.

Is het uberhaupt mogelijk en zo ja kan iemand mij op weg helpen ?
Google, Got en msdn bieden mij geen uitkomst.

alvast bedankt.

[sopsop]

Jij hebt die variabelen hardcoded in je applicatie staan? De vraag is denk ik niet hoe je die kunt opzoeken, maar hoe je dit beter kunt aanpakken.

Ik noem een dwarsstraat: maak een class waarin je een waarde en een naam property hebt, maak vervolgens een collectie (array) van het type van de class die je net hebt gemaakt en zet daar de variabelenamen en de bijbehorende waarden in.

Of je gebruiker een value-key collection.

Lees dit eens door: http://it.maconstate.edu/...T/VBNET01/vbnet01-03.aspx

[ Voor 14% gewijzigd door sopsop op 16-09-2008 09:25 ]

[Verwijderd]

Die variablen staan inderdaad hardcoded in mn applicatie aangezien er berekeningen mee worden uitgevoerd. ze hoeven alleen niet bij elke configuratie worden doorgestuurd. Belangrijk is wel dat ze een goede herkenbare naam hebben dus een array is voor mij geen oplossing.

evengoed bedankt

[ Voor 3% gewijzigd door Verwijderd op 16-09-2008 17:46 . Reden: bedankje ]

[TeeDee]

Bedoel je niet gewoon een List<..>? Eventueel kan je je even inlezen op strongly typed lists.

En anders bouw je een wrapper class voor al je parameters (minder fijn als deze ook nog eens regelmatig wijzigen) in combinatie met get/set oftewel properties.

[ Voor 46% gewijzigd door TeeDee op 16-09-2008 17:56 ]

[Verwijderd]

Ik had gehoopt dat er eigenlijk een manier was om net zoals je controls op kan zoeken ook variabelen van het type integer op kan zoeken.

[Verwijderd]

Ik zou 't (zoals hieboven ook al gezegd) zoeken in Dictionary<> en KeyValuePair oplossingen.
Via reflection kun je ook wel bij de variabelen komen, maar handig of mooi is 't niet...

[Verwijderd]

Hoezo is dat niet mooi of handig ?
Ik weet de naam al van de var waarvan ik de waarde wil weten.

Ik ga wel even verder zoeken. Ik heb het idee dat ik mn vraag niet duidelijk genoeg gesteld heb.

[TeeDee]

Verwijderd schreef op dinsdag 16 september 2008 @ 19:23:
Ik heb het idee dat ik mn vraag niet duidelijk genoeg gesteld heb.

Dat heeft er inderdaad mee te maken.

Andere mogelijkheid is om middels Enums de parameters te reflecteren in je database en die met een Enum.Parse oid in te lezen.

[Verwijderd]

Hoeveel variabelen heb je dan?

Is het niet makkelijker om met inventor de parameters te linken naar een excel sheet?

[RobIII]

Verwijderd schreef op dinsdag 16 september 2008 @ 20:32:
Hoeveel variabelen heb je dan?

Is het niet makkelijker om met inventor de parameters te linken naar een excel sheet?

Ja joh, zijn probleem is nog niet groot genoeg. Sleep er ook nog effe excel bij
Een Dictionary (of gelijkaardige collectie) is hiervoor het simpelst en makkelijkst te implementeren.

[Verwijderd]

Hoeveel variabelen ik heb ? uiteindelijk denk ik toch wel een stuk of 80 als het project gerealiseerd is.

Ik stap juist van excel af omdat je op een gegeven moment door de bomen het bos niet meer ziet qua formules in excel en omdat ik een stukje historie wil gaan opbouwen qua configuraties.
Ook wil ik parameters teruggekoppeld hebben wat in excel niet gaat.

Ik ga dus kijken wat ik met dictionary kan doen. Ik hoop dat ik hiermee het probleem kan afvangen.

Het is namelijk wel heel belangrijk voor me dat ik in designtime formules kan berekenen aan de hand van variabelen.

Maar inventor vind het niet grappig als ik parameters naar hem toe druk die niet bestaan.
Dus vandaar dat ik per configuratie een selectie van variabelen(de namen van die variabelen dus) uit de database trek waar het programma dan de berekende waarde bij zoekt en die weer terug kan sturen naar inventor.

[Verwijderd]

Ik gooi de waardes van de variablen wel eerst naar een label toe.
Dan heb ik meteen een debug scherm zodat ik op de achtergrond kan zien welke waardes er berekend zijn.

Kan in de toekomst nog wel eens handig zijn. Gewoon een apart formulier wat op de achtergrond meedraaid.

Bedankt voor jullie hulp.

[Woy]

Waarom doe je niet zoals al voorgesteld met een Dictionary?

Dat lijkt me een stuk makkelijker dan eerst alles in een Label stoppen en dan weer gaan parsen enzo.

[BramFokke]

Verwijderd schreef op maandag 22 september 2008 @ 19:36:
Ik gooi de waardes van de variablen wel eerst naar een label toe.
Dan heb ik meteen een debug scherm zodat ik op de achtergrond kan zien welke waardes er berekend zijn.

Kan in de toekomst nog wel eens handig zijn. Gewoon een apart formulier wat op de achtergrond meedraaid.

Bedankt voor jullie hulp.

Ik ken je specifieke situatie niet maar ik kan me bijna niet voorstellen dat dit echt de beste architectuur is om een probleem op te lossen. Als ik jou was zou ik me eens inlezen over wat allemaal kan met de VB.Net debugger. Want het lijkt er nu op dat je gegevens uitwisselt via de gebruikersinterface om makkelijk te kunnen debuggen. En daarvoor is de debugger speciaal bedoeld. Daarnaast is een van de meest basale 'rules of thumb' bij vrijwel iedere architectuur dat je presentatie en logica moet scheiden, zodat je niet alles opnieuw aan het schrijven bent als je opeens moet werken over een webservice o.i.d.

[Verwijderd]

rwb schreef op maandag 22 september 2008 @ 20:15:
Waarom doe je niet zoals al voorgesteld met een Dictionary?

Dat lijkt me een stuk makkelijker dan eerst alles in een Label stoppen en dan weer gaan parsen enzo.

Omdat ik harde variabelen (integers en doubles) in mn applicatie heb staan die allemaal doorgerekend moeten worden. Alleen per model hoeven de uitkomsten die nu in deze variabelen zitten niet allemaal doorgezonden te worden.

En als ik het goed begrepen heb kan je met een dictionary in runtime variabelen aanmaken. Alleen is hiet dan niet meer mee te rekenen aangezien de formules ook hardcoded in de applicatie staan.

[Verwijderd]

BramFokke schreef op dinsdag 23 september 2008 @ 14:56:
[...]

Ik ken je specifieke situatie niet maar ik kan me bijna niet voorstellen dat dit echt de beste architectuur is om een probleem op te lossen. Als ik jou was zou ik me eens inlezen over wat allemaal kan met de VB.Net debugger. Want het lijkt er nu op dat je gegevens uitwisselt via de gebruikersinterface om makkelijk te kunnen debuggen. En daarvoor is de debugger speciaal bedoeld. Daarnaast is een van de meest basale 'rules of thumb' bij vrijwel iedere architectuur dat je presentatie en logica moet scheiden, zodat je niet alles opnieuw aan het schrijven bent als je opeens moet werken over een webservice o.i.d.

Heeft niks met de debugger te maken. Ik wil gewoon bepaalde antwoorden terug sturen naar het model.en aangezien ik wel waardes uit controls kan uitlezen en geen waardes uit variabelen pleur ik het wel allemaal in labels op een niet zichtbaar formulier en stuur ik ze zo door.

[whoami]

Een control is eigenlijk ook niets meer dan een (member) variable van je form (of van je container control) hoor ...

[BramFokke]

Als ik jou was zou ik eens kijken naar reflection. Want op die manier kan je wel dynamisch variabelen in je programma aanpassen. Je zou een class kunnen maken die alle variabelen die je wilt aanpassen bevat.

[Woy]

BramFokke schreef op dinsdag 23 september 2008 @ 15:55:
Als ik jou was zou ik eens kijken naar reflection. Want op die manier kan je wel dynamisch variabelen in je programma aanpassen. Je zou een class kunnen maken die alle variabelen die je wilt aanpassen bevat.

Maar wat is in deze situatie het voordeel van reflectie? Voordat je iets met reflection gaat doen moet je daar wel goede redenen voor hebben, want vaak is het helemaal niet nodig.

Ik zou nog steeds opteren voor iets met een Dictionary. Als je het al via Labels kunt doen zie ik helemaal niet in waarom het niet via een Dictionary mogenlijk is?

Mischien kan de TS een stukje voorbeeld ( pseudo ) code laten zien wat hij precies wil doen.

[ Voor 6% gewijzigd door Woy op 23-09-2008 16:26 ]

[sopsop]

Verwijderd schreef op dinsdag 23 september 2008 @ 15:21:
[...]

En als ik het goed begrepen heb kan je met een dictionary in runtime variabelen aanmaken. Alleen is hiet dan niet meer mee te rekenen aangezien de formules ook hardcoded in de applicatie staan.

Huh?
Je kunt van die formule toch gewoon een functie maken met input parameters. Die functie roep je vervolgens gewoon aan met je variabelen die je in je dictionairy hebt staan. 't Is niet echt rocketscience hoor.

[BramFokke]

rwb schreef op dinsdag 23 september 2008 @ 16:25:
[...]

Maar wat is in deze situatie het voordeel van reflectie? Voordat je iets met reflection gaat doen moet je daar wel goede redenen voor hebben, want vaak is het helemaal niet nodig.

Ik zou nog steeds opteren voor iets met een Dictionary. Als je het al via Labels kunt doen zie ik helemaal niet in waarom het niet via een Dictionary mogenlijk is?

Mischien kan de TS een stukje voorbeeld ( pseudo ) code laten zien wat hij precies wil doen.

Als het gaat om een aantal simpele parameters, dan is een dictionary inderdaad het beste. Maar ik kan me voorstellen dat de configuraties complexer zijn dan dat. Als je subconfiguraties hebt, dan wordt een Dictionary al snel onwerkbaar.

Stel: het gaat om de configuratie van een auto. Dat is veel mooie gemodelleerd als een objectmodel dan als een stel platte parameters:

C#:

public class CarConfiguration {
    public float EngineHP = 210;
    public int EngineCylinders = 6;

    public List<Option> Options = new List<Option>(new Option[] {
        new SpinningReels(),
        new UberStereo(),
        new CupHolder(),
        new CupHolder() { Position = "Aft" }
    });

   public class Option {
      public decimal Price;
   }

    public class SpinningReels : Option {
        public string HubType = "50 Cent";
    }

    public class UberStereo : Option {
        public int SpeakerWatt = 100;
    }

    public class Cupholder : Option {
       public string Position = "Dashboard";
    }
}