|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
My.Settings Questionsreally cool the way the IDE allows you create it, etc. I have an implementation question: I haved this: - general LoginForm in a class library (DLL) - A multi-user application (EXE) Application is run from a share drive, each user has its own credentials he can save on his PC. Overall, what is recommended approach use MySettings here from the standpoint of passing and/or where the form will initialize its fields? The form has: UserName: Password: [_] Remember Credentials [_] Auto Login (_) Use Local Server (_) Pick Server (_) Use this server ________________ The question is this: Should the EXE has the My.Settings and prepare the login form before doing a ShowDialog or can I do this in the Loginform class Load event by passing My.Settings to the constructor? For example: Public Class LoginForm Public UserSettings As My.Settings Private Sub LoginForm_Load( _ ByVal sender As Object, _ ByVal e As System.EventArgs) Handles Me.Load chkRemember.Checked = UserSettings.UseRemember <-- invalid chkAutoLogin.Checked = UserSettings.UseAutoLogin <-- invalid etc ... End Sub End Class The problem is that compiler issues the error: error BC30909: 'UserSettings' cannot expose type 'My.MySettings' outside the project through class 'LoginForm'. Of course, I can do this outside the form or maybe use properties from outside the form. Is that the way or is there another method? Thanks -- Mike,
The my.Settings is build to make a bridge between VB6 users and Net It works like VB6 Cor Show quoteHide quote "Mike" <unkn***@unknown.tv> wrote in message news:OPoC8Ea5JHA.6136@TK2MSFTNGP03.phx.gbl... >I just started using My.Settings in my VB.NET project. I think its really >cool the way the IDE allows you create it, etc. > > I have an implementation question: > > I haved this: > > - general LoginForm in a class library (DLL) > > - A multi-user application (EXE) > > Application is run from a share drive, each user > has its own credentials he can save on his PC. > > Overall, what is recommended approach use MySettings here from the > standpoint of passing and/or where the form will initialize its fields? > > The form has: > > UserName: > Password: > > [_] Remember Credentials > [_] Auto Login > > (_) Use Local Server > (_) Pick Server > (_) Use this server ________________ > > The question is this: > > Should the EXE has the My.Settings and prepare the login form before doing > a ShowDialog or can I do this in the Loginform class Load event by passing > My.Settings to the constructor? > > For example: > > Public Class LoginForm > > Public UserSettings As My.Settings > > Private Sub LoginForm_Load( _ > ByVal sender As Object, _ > ByVal e As System.EventArgs) Handles Me.Load > > chkRemember.Checked = UserSettings.UseRemember <-- invalid > chkAutoLogin.Checked = UserSettings.UseAutoLogin <-- invalid > etc > ... > End Sub > End Class > > The problem is that compiler issues the error: > > error BC30909: 'UserSettings' cannot expose type 'My.MySettings' outside > the project through class 'LoginForm'. > > Of course, I can do this outside the form or maybe use properties from > outside the form. > > Is that the way or is there another method? > > Thanks > > -- > I never really used VB6 at this level.
Overall, I have Project.EXE ControlLibrary.DLL There is a FORM in the library. I need to make the DLL use the Application My.Settings. -- Show quoteHide quoteCor Ligthert[MVP] wrote: > Mike, > > The my.Settings is build to make a bridge between VB6 users and Net > > It works like VB6 > > Cor > > > "Mike" <unkn***@unknown.tv> wrote in message > news:OPoC8Ea5JHA.6136@TK2MSFTNGP03.phx.gbl... >> I just started using My.Settings in my VB.NET project. I think its >> really cool the way the IDE allows you create it, etc. >> >> I have an implementation question: >> >> I haved this: >> >> - general LoginForm in a class library (DLL) >> >> - A multi-user application (EXE) >> >> Application is run from a share drive, each user >> has its own credentials he can save on his PC. >> >> Overall, what is recommended approach use MySettings here from the >> standpoint of passing and/or where the form will initialize its fields? >> >> The form has: >> >> UserName: >> Password: >> >> [_] Remember Credentials >> [_] Auto Login >> >> (_) Use Local Server >> (_) Pick Server >> (_) Use this server ________________ >> >> The question is this: >> >> Should the EXE has the My.Settings and prepare the login form before >> doing a ShowDialog or can I do this in the Loginform class Load event >> by passing My.Settings to the constructor? >> >> For example: >> >> Public Class LoginForm >> >> Public UserSettings As My.Settings >> >> Private Sub LoginForm_Load( _ >> ByVal sender As Object, _ >> ByVal e As System.EventArgs) Handles Me.Load >> >> chkRemember.Checked = UserSettings.UseRemember <-- invalid >> chkAutoLogin.Checked = UserSettings.UseAutoLogin <-- invalid >> etc >> ... >> End Sub >> End Class >> >> The problem is that compiler issues the error: >> >> error BC30909: 'UserSettings' cannot expose type 'My.MySettings' >> outside the project through class 'LoginForm'. >> >> Of course, I can do this outside the form or maybe use properties from >> outside the form. >> >> Is that the way or is there another method? >> >> Thanks >> >> -- >> > Hello Mike
You do not need to pass a my.settings instance to the constructor you can just use the common my.settings fields inside your class as the settings are used from the calling assembly So you define the same properties in both projects but during runtime the farmework automaticly uses the properties from the calling assembly ( the exe ) in fact you need to perfom some extra coding if you want to use the setting stored in the config from the called assembly ( the dll ) HTH Michel Posseth Show quoteHide quote "Mike" <unkn***@unknown.tv> schreef in bericht news:es4TJeb5JHA.3860@TK2MSFTNGP05.phx.gbl... >I never really used VB6 at this level. > > Overall, I have > > Project.EXE > ControlLibrary.DLL > > There is a FORM in the library. I need to make the DLL use the Application > My.Settings. > > -- > > > Cor Ligthert[MVP] wrote: >> Mike, >> >> The my.Settings is build to make a bridge between VB6 users and Net >> >> It works like VB6 >> >> Cor >> >> >> "Mike" <unkn***@unknown.tv> wrote in message >> news:OPoC8Ea5JHA.6136@TK2MSFTNGP03.phx.gbl... >>> I just started using My.Settings in my VB.NET project. I think its >>> really cool the way the IDE allows you create it, etc. >>> >>> I have an implementation question: >>> >>> I haved this: >>> >>> - general LoginForm in a class library (DLL) >>> >>> - A multi-user application (EXE) >>> >>> Application is run from a share drive, each user >>> has its own credentials he can save on his PC. >>> >>> Overall, what is recommended approach use MySettings here from the >>> standpoint of passing and/or where the form will initialize its fields? >>> >>> The form has: >>> >>> UserName: >>> Password: >>> >>> [_] Remember Credentials >>> [_] Auto Login >>> >>> (_) Use Local Server >>> (_) Pick Server >>> (_) Use this server ________________ >>> >>> The question is this: >>> >>> Should the EXE has the My.Settings and prepare the login form before >>> doing a ShowDialog or can I do this in the Loginform class Load event by >>> passing My.Settings to the constructor? >>> >>> For example: >>> >>> Public Class LoginForm >>> >>> Public UserSettings As My.Settings >>> >>> Private Sub LoginForm_Load( _ >>> ByVal sender As Object, _ >>> ByVal e As System.EventArgs) Handles Me.Load >>> >>> chkRemember.Checked = UserSettings.UseRemember <-- invalid >>> chkAutoLogin.Checked = UserSettings.UseAutoLogin <-- invalid >>> etc >>> ... >>> End Sub >>> End Class >>> >>> The problem is that compiler issues the error: >>> >>> error BC30909: 'UserSettings' cannot expose type 'My.MySettings' outside >>> the project through class 'LoginForm'. >>> >>> Of course, I can do this outside the form or maybe use properties from >>> outside the form. >>> >>> Is that the way or is there another method? >>> >>> Thanks >>> >>> -- >>> >> Yes, I finally figured it out after playing with ConfigurationManager
and RoamingUserANdLocal stuff to get the application user.config. I ended up not needed it but it lead me to what you are saying. The user.config will contain a userSettings for the EXE and DLL. Duplicated it but the ended just the one in the DLL since it is self contained and used properties to all the EXE to setup if it needs too. thanks for your input -- Show quoteHide quoteMichel Posseth [MCP] wrote: > Hello Mike > > You do not need to pass a my.settings instance to the constructor > you can just use the common my.settings fields inside your class > as the settings are used from the calling assembly > > So you define the same properties in both projects but during runtime the > farmework automaticly uses the properties from the calling assembly ( the > exe ) in fact you need to perfom some extra coding if you want to use the > setting stored in the config from the called assembly ( the dll ) > > HTH > > Michel Posseth > > > > "Mike" <unkn***@unknown.tv> schreef in bericht > news:es4TJeb5JHA.3860@TK2MSFTNGP05.phx.gbl... >> I never really used VB6 at this level. >> >> Overall, I have >> >> Project.EXE >> ControlLibrary.DLL >> >> There is a FORM in the library. I need to make the DLL use the Application >> My.Settings. >> >> -- >> >> >> Cor Ligthert[MVP] wrote: >>> Mike, >>> >>> The my.Settings is build to make a bridge between VB6 users and Net >>> >>> It works like VB6 >>> >>> Cor >>> >>> >>> "Mike" <unkn***@unknown.tv> wrote in message >>> news:OPoC8Ea5JHA.6136@TK2MSFTNGP03.phx.gbl... >>>> I just started using My.Settings in my VB.NET project. I think its >>>> really cool the way the IDE allows you create it, etc. >>>> >>>> I have an implementation question: >>>> >>>> I haved this: >>>> >>>> - general LoginForm in a class library (DLL) >>>> >>>> - A multi-user application (EXE) >>>> >>>> Application is run from a share drive, each user >>>> has its own credentials he can save on his PC. >>>> >>>> Overall, what is recommended approach use MySettings here from the >>>> standpoint of passing and/or where the form will initialize its fields? >>>> >>>> The form has: >>>> >>>> UserName: >>>> Password: >>>> >>>> [_] Remember Credentials >>>> [_] Auto Login >>>> >>>> (_) Use Local Server >>>> (_) Pick Server >>>> (_) Use this server ________________ >>>> >>>> The question is this: >>>> >>>> Should the EXE has the My.Settings and prepare the login form before >>>> doing a ShowDialog or can I do this in the Loginform class Load event by >>>> passing My.Settings to the constructor? >>>> >>>> For example: >>>> >>>> Public Class LoginForm >>>> >>>> Public UserSettings As My.Settings >>>> >>>> Private Sub LoginForm_Load( _ >>>> ByVal sender As Object, _ >>>> ByVal e As System.EventArgs) Handles Me.Load >>>> >>>> chkRemember.Checked = UserSettings.UseRemember <-- invalid >>>> chkAutoLogin.Checked = UserSettings.UseAutoLogin <-- invalid >>>> etc >>>> ... >>>> End Sub >>>> End Class >>>> >>>> The problem is that compiler issues the error: >>>> >>>> error BC30909: 'UserSettings' cannot expose type 'My.MySettings' outside >>>> the project through class 'LoginForm'. >>>> >>>> Of course, I can do this outside the form or maybe use properties from >>>> outside the form. >>>> >>>> Is that the way or is there another method? >>>> >>>> Thanks >>>> >>>> -- >>>> > > > The my.Settings is build to make a bridge between VB6 users and Net writers of the core reference guide of VB6 as> > It works like VB6 :-| Huh ???? ,,,,, well then i sure missed something in VB6 and also the there is nothing stated in there ( just checked to be sure ) about something that is even close to the my.settings namespace This is what MSFT tells about the My namespace My Namespace The My namespace in Visual Basic exposes properties and methods that enable you to easily take advantage of the power of the .NET Framework. The My namespace simplifies common programming problems, often reducing a difficult task to a single line of code. Additionally, the My namespace is fully extensible so that you can customize the behavior of My and add new services to its hierarchy to adapt to specific application needs. >> So the my namespace is just a collection of shortcuts in the .Net framework wich is extensible to your own needs and has nothing to do what so ever with VB legacy a VB legacy coder would not even know what you are talking about if you would confront him with "My.Settings" HTH Michel Show quoteHide quote "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> schreef in bericht news:%23uQVxDb5JHA.1420@TK2MSFTNGP04.phx.gbl... > Mike, > > The my.Settings is build to make a bridge between VB6 users and Net > > It works like VB6 > > Cor > > > "Mike" <unkn***@unknown.tv> wrote in message > news:OPoC8Ea5JHA.6136@TK2MSFTNGP03.phx.gbl... >>I just started using My.Settings in my VB.NET project. I think its really >>cool the way the IDE allows you create it, etc. >> >> I have an implementation question: >> >> I haved this: >> >> - general LoginForm in a class library (DLL) >> >> - A multi-user application (EXE) >> >> Application is run from a share drive, each user >> has its own credentials he can save on his PC. >> >> Overall, what is recommended approach use MySettings here from the >> standpoint of passing and/or where the form will initialize its fields? >> >> The form has: >> >> UserName: >> Password: >> >> [_] Remember Credentials >> [_] Auto Login >> >> (_) Use Local Server >> (_) Pick Server >> (_) Use this server ________________ >> >> The question is this: >> >> Should the EXE has the My.Settings and prepare the login form before >> doing a ShowDialog or can I do this in the Loginform class Load event by >> passing My.Settings to the constructor? >> >> For example: >> >> Public Class LoginForm >> >> Public UserSettings As My.Settings >> >> Private Sub LoginForm_Load( _ >> ByVal sender As Object, _ >> ByVal e As System.EventArgs) Handles Me.Load >> >> chkRemember.Checked = UserSettings.UseRemember <-- invalid >> chkAutoLogin.Checked = UserSettings.UseAutoLogin <-- invalid >> etc >> ... >> End Sub >> End Class >> >> The problem is that compiler issues the error: >> >> error BC30909: 'UserSettings' cannot expose type 'My.MySettings' outside >> the project through class 'LoginForm'. >> >> Of course, I can do this outside the form or maybe use properties from >> outside the form. >> >> Is that the way or is there another method? >> >> Thanks >> >> -- >> > Michel,
I know a company who uses the old brown coal from East Germany, they describe it a little bit in the same way like you. Was you ever there? :-) (I was)Cor Show quoteHide quote "Michel Posseth [MCP]" <M***@posseth.com> wrote in message news:%23F38ICf5JHA.4332@TK2MSFTNGP06.phx.gbl... >> The my.Settings is build to make a bridge between VB6 users and Net >> >> It works like VB6 > > > :-| Huh ???? ,,,,, well then i sure missed something in VB6 and also > the writers of the core reference guide of VB6 as > there is nothing stated in there ( just checked to be sure ) about > something that is even close to the my.settings namespace > > > This is what MSFT tells about the My namespace > > My Namespace > The My namespace in Visual Basic exposes properties and methods that > enable you to easily take advantage of the power of the .NET Framework. > The My namespace simplifies common programming problems, often reducing a > difficult task to a single line of code. Additionally, the My namespace is > fully extensible so that you can customize the behavior of My and add new > services to its hierarchy to adapt to specific application needs. > >>> > > So the my namespace is just a collection of shortcuts in the .Net > framework wich is extensible to your own needs and has nothing to do what > so ever with VB legacy a VB legacy coder would not even know what you are > talking about if you would confront him with "My.Settings" > > > > HTH > > > > Michel > > > > > > > > > "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> schreef in bericht > news:%23uQVxDb5JHA.1420@TK2MSFTNGP04.phx.gbl... >> Mike, >> >> The my.Settings is build to make a bridge between VB6 users and Net >> >> It works like VB6 >> >> Cor >> >> >> "Mike" <unkn***@unknown.tv> wrote in message >> news:OPoC8Ea5JHA.6136@TK2MSFTNGP03.phx.gbl... >>>I just started using My.Settings in my VB.NET project. I think its really >>>cool the way the IDE allows you create it, etc. >>> >>> I have an implementation question: >>> >>> I haved this: >>> >>> - general LoginForm in a class library (DLL) >>> >>> - A multi-user application (EXE) >>> >>> Application is run from a share drive, each user >>> has its own credentials he can save on his PC. >>> >>> Overall, what is recommended approach use MySettings here from the >>> standpoint of passing and/or where the form will initialize its fields? >>> >>> The form has: >>> >>> UserName: >>> Password: >>> >>> [_] Remember Credentials >>> [_] Auto Login >>> >>> (_) Use Local Server >>> (_) Pick Server >>> (_) Use this server ________________ >>> >>> The question is this: >>> >>> Should the EXE has the My.Settings and prepare the login form before >>> doing a ShowDialog or can I do this in the Loginform class Load event by >>> passing My.Settings to the constructor? >>> >>> For example: >>> >>> Public Class LoginForm >>> >>> Public UserSettings As My.Settings >>> >>> Private Sub LoginForm_Load( _ >>> ByVal sender As Object, _ >>> ByVal e As System.EventArgs) Handles Me.Load >>> >>> chkRemember.Checked = UserSettings.UseRemember <-- invalid >>> chkAutoLogin.Checked = UserSettings.UseAutoLogin <-- invalid >>> etc >>> ... >>> End Sub >>> End Class >>> >>> The problem is that compiler issues the error: >>> >>> error BC30909: 'UserSettings' cannot expose type 'My.MySettings' outside >>> the project through class 'LoginForm'. >>> >>> Of course, I can do this outside the form or maybe use properties from >>> outside the form. >>> >>> Is that the way or is there another method? >>> >>> Thanks >>> >>> -- >>> >> > > Sorry but i have no idea what you are trying to tell , i am probably missing
something Michel Show quoteHide quote "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> schreef in bericht news:ep619$g5JHA.1420@TK2MSFTNGP04.phx.gbl... > Michel, > > I know a company who uses the old brown coal from East Germany, they > describe it a little bit in the same way like you. > > Was you ever there? > > :-) > > (I was) > > Cor > > > "Michel Posseth [MCP]" <M***@posseth.com> wrote in message > news:%23F38ICf5JHA.4332@TK2MSFTNGP06.phx.gbl... >>> The my.Settings is build to make a bridge between VB6 users and Net >>> >>> It works like VB6 >> >> >> :-| Huh ???? ,,,,, well then i sure missed something in VB6 and also >> the writers of the core reference guide of VB6 as >> there is nothing stated in there ( just checked to be sure ) about >> something that is even close to the my.settings namespace >> >> >> This is what MSFT tells about the My namespace >> >> My Namespace >> The My namespace in Visual Basic exposes properties and methods that >> enable you to easily take advantage of the power of the .NET Framework. >> The My namespace simplifies common programming problems, often reducing a >> difficult task to a single line of code. Additionally, the My namespace >> is fully extensible so that you can customize the behavior of My and add >> new services to its hierarchy to adapt to specific application needs. >> >>>> >> >> So the my namespace is just a collection of shortcuts in the .Net >> framework wich is extensible to your own needs and has nothing to do >> what so ever with VB legacy a VB legacy coder would not even know what >> you are talking about if you would confront him with "My.Settings" >> >> >> >> HTH >> >> >> >> Michel >> >> >> >> >> >> >> >> >> "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> schreef in bericht >> news:%23uQVxDb5JHA.1420@TK2MSFTNGP04.phx.gbl... >>> Mike, >>> >>> The my.Settings is build to make a bridge between VB6 users and Net >>> >>> It works like VB6 >>> >>> Cor >>> >>> >>> "Mike" <unkn***@unknown.tv> wrote in message >>> news:OPoC8Ea5JHA.6136@TK2MSFTNGP03.phx.gbl... >>>>I just started using My.Settings in my VB.NET project. I think its >>>>really cool the way the IDE allows you create it, etc. >>>> >>>> I have an implementation question: >>>> >>>> I haved this: >>>> >>>> - general LoginForm in a class library (DLL) >>>> >>>> - A multi-user application (EXE) >>>> >>>> Application is run from a share drive, each user >>>> has its own credentials he can save on his PC. >>>> >>>> Overall, what is recommended approach use MySettings here from the >>>> standpoint of passing and/or where the form will initialize its fields? >>>> >>>> The form has: >>>> >>>> UserName: >>>> Password: >>>> >>>> [_] Remember Credentials >>>> [_] Auto Login >>>> >>>> (_) Use Local Server >>>> (_) Pick Server >>>> (_) Use this server ________________ >>>> >>>> The question is this: >>>> >>>> Should the EXE has the My.Settings and prepare the login form before >>>> doing a ShowDialog or can I do this in the Loginform class Load event >>>> by passing My.Settings to the constructor? >>>> >>>> For example: >>>> >>>> Public Class LoginForm >>>> >>>> Public UserSettings As My.Settings >>>> >>>> Private Sub LoginForm_Load( _ >>>> ByVal sender As Object, _ >>>> ByVal e As System.EventArgs) Handles Me.Load >>>> >>>> chkRemember.Checked = UserSettings.UseRemember <-- invalid >>>> chkAutoLogin.Checked = UserSettings.UseAutoLogin <-- invalid >>>> etc >>>> ... >>>> End Sub >>>> End Class >>>> >>>> The problem is that compiler issues the error: >>>> >>>> error BC30909: 'UserSettings' cannot expose type 'My.MySettings' >>>> outside the project through class 'LoginForm'. >>>> >>>> Of course, I can do this outside the form or maybe use properties from >>>> outside the form. >>>> >>>> Is that the way or is there another method? >>>> >>>> Thanks >>>> >>>> -- >>>> >>> >> >> > Michel,
You show me a text which is in my idea full of marketing sentences, I want to show you with a same text that everything that is written is not always the complete truth. Check the opinion from others active in this newsgroup about the My namespace. Cor Show quoteHide quote "Michel Posseth [MCP]" <M***@posseth.com> wrote in message news:OyH3HMh5JHA.1424@TK2MSFTNGP02.phx.gbl... > > Sorry but i have no idea what you are trying to tell , i am probably > missing something > > Michel > > > > > "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> schreef in bericht > news:ep619$g5JHA.1420@TK2MSFTNGP04.phx.gbl... >> Michel, >> >> I know a company who uses the old brown coal from East Germany, they >> describe it a little bit in the same way like you. >> >> Was you ever there? >> >> :-) >> >> (I was) >> >> Cor >> >> >> "Michel Posseth [MCP]" <M***@posseth.com> wrote in message >> news:%23F38ICf5JHA.4332@TK2MSFTNGP06.phx.gbl... >>>> The my.Settings is build to make a bridge between VB6 users and Net >>>> >>>> It works like VB6 >>> >>> >>> :-| Huh ???? ,,,,, well then i sure missed something in VB6 and also >>> the writers of the core reference guide of VB6 as >>> there is nothing stated in there ( just checked to be sure ) about >>> something that is even close to the my.settings namespace >>> >>> >>> This is what MSFT tells about the My namespace >>> >>> My Namespace >>> The My namespace in Visual Basic exposes properties and methods that >>> enable you to easily take advantage of the power of the .NET Framework. >>> The My namespace simplifies common programming problems, often reducing >>> a difficult task to a single line of code. Additionally, the My >>> namespace is fully extensible so that you can customize the behavior of >>> My and add new services to its hierarchy to adapt to specific >>> application needs. >>> >>>>> >>> >>> So the my namespace is just a collection of shortcuts in the .Net >>> framework wich is extensible to your own needs and has nothing to do >>> what so ever with VB legacy a VB legacy coder would not even know what >>> you are talking about if you would confront him with "My.Settings" >>> >>> >>> >>> HTH >>> >>> >>> >>> Michel >>> >>> >>> >>> >>> >>> >>> >>> >>> "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> schreef in bericht >>> news:%23uQVxDb5JHA.1420@TK2MSFTNGP04.phx.gbl... >>>> Mike, >>>> >>>> The my.Settings is build to make a bridge between VB6 users and Net >>>> >>>> It works like VB6 >>>> >>>> Cor >>>> >>>> >>>> "Mike" <unkn***@unknown.tv> wrote in message >>>> news:OPoC8Ea5JHA.6136@TK2MSFTNGP03.phx.gbl... >>>>>I just started using My.Settings in my VB.NET project. I think its >>>>>really cool the way the IDE allows you create it, etc. >>>>> >>>>> I have an implementation question: >>>>> >>>>> I haved this: >>>>> >>>>> - general LoginForm in a class library (DLL) >>>>> >>>>> - A multi-user application (EXE) >>>>> >>>>> Application is run from a share drive, each user >>>>> has its own credentials he can save on his PC. >>>>> >>>>> Overall, what is recommended approach use MySettings here from the >>>>> standpoint of passing and/or where the form will initialize its >>>>> fields? >>>>> >>>>> The form has: >>>>> >>>>> UserName: >>>>> Password: >>>>> >>>>> [_] Remember Credentials >>>>> [_] Auto Login >>>>> >>>>> (_) Use Local Server >>>>> (_) Pick Server >>>>> (_) Use this server ________________ >>>>> >>>>> The question is this: >>>>> >>>>> Should the EXE has the My.Settings and prepare the login form before >>>>> doing a ShowDialog or can I do this in the Loginform class Load event >>>>> by passing My.Settings to the constructor? >>>>> >>>>> For example: >>>>> >>>>> Public Class LoginForm >>>>> >>>>> Public UserSettings As My.Settings >>>>> >>>>> Private Sub LoginForm_Load( _ >>>>> ByVal sender As Object, _ >>>>> ByVal e As System.EventArgs) Handles Me.Load >>>>> >>>>> chkRemember.Checked = UserSettings.UseRemember <-- invalid >>>>> chkAutoLogin.Checked = UserSettings.UseAutoLogin <-- invalid >>>>> etc >>>>> ... >>>>> End Sub >>>>> End Class >>>>> >>>>> The problem is that compiler issues the error: >>>>> >>>>> error BC30909: 'UserSettings' cannot expose type 'My.MySettings' >>>>> outside the project through class 'LoginForm'. >>>>> >>>>> Of course, I can do this outside the form or maybe use properties from >>>>> outside the form. >>>>> >>>>> Is that the way or is there another method? >>>>> >>>>> Thanks >>>>> >>>>> -- >>>>> >>>> >>> >>> >> > > "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message That's very funny coming from you Ligthert. You're a marketing man's wet news:uhUzalm5JHA.3860@TK2MSFTNGP05.phx.gbl... > Michel [Michel Posseth], You show me a text which is > in my idea full of marketing sentences . . . dream. In fact you even look as though you've just had a wet dream judging by your MVP photo. You've swallowed all the Micto$oft marketing lies hook, line and sinker. You're nothing but a Micro$oft stooge, Ligthert. Why don't you just give back your annual MVP trinkets and become yourself again. Have you no self respect? Mike
Show quote
Hide quote
"Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message You know I have been listening to your off topic comments for quite a while news:ep619$g5JHA.1420@TK2MSFTNGP04.phx.gbl... > Michel, > > I know a company who uses the old brown coal from East Germany, they > describe it a little bit in the same way like you. > > Was you ever there? > > :-) > > (I was) > > Cor > > > "Michel Posseth [MCP]" <M***@posseth.com> wrote in message > news:%23F38ICf5JHA.4332@TK2MSFTNGP06.phx.gbl... >>> The my.Settings is build to make a bridge between VB6 users and Net >>> >>> It works like VB6 >> >> >> :-| Huh ???? ,,,,, well then i sure missed something in VB6 and also >> the writers of the core reference guide of VB6 as >> there is nothing stated in there ( just checked to be sure ) about >> something that is even close to the my.settings namespace >> >> >> This is what MSFT tells about the My namespace >> >> My Namespace >> The My namespace in Visual Basic exposes properties and methods that >> enable you to easily take advantage of the power of the .NET Framework. >> The My namespace simplifies common programming problems, often reducing a >> difficult task to a single line of code. Additionally, the My namespace >> is fully extensible so that you can customize the behavior of My and add >> new services to its hierarchy to adapt to specific application needs. >> >>>> >> >> So the my namespace is just a collection of shortcuts in the .Net >> framework wich is extensible to your own needs and has nothing to do >> what so ever with VB legacy a VB legacy coder would not even know what >> you are talking about if you would confront him with "My.Settings" >> >> >> >> HTH >> >> >> >> Michel >> >> >> >> >> >> >> >> >> "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> schreef in bericht >> news:%23uQVxDb5JHA.1420@TK2MSFTNGP04.phx.gbl... >>> Mike, >>> >>> The my.Settings is build to make a bridge between VB6 users and Net >>> >>> It works like VB6 >>> >>> Cor >>> >>> >>> "Mike" <unkn***@unknown.tv> wrote in message >>> news:OPoC8Ea5JHA.6136@TK2MSFTNGP03.phx.gbl... >>>>I just started using My.Settings in my VB.NET project. I think its >>>>really cool the way the IDE allows you create it, etc. >>>> >>>> I have an implementation question: >>>> >>>> I haved this: >>>> >>>> - general LoginForm in a class library (DLL) >>>> >>>> - A multi-user application (EXE) >>>> >>>> Application is run from a share drive, each user >>>> has its own credentials he can save on his PC. >>>> >>>> Overall, what is recommended approach use MySettings here from the >>>> standpoint of passing and/or where the form will initialize its fields? >>>> >>>> The form has: >>>> >>>> UserName: >>>> Password: >>>> >>>> [_] Remember Credentials >>>> [_] Auto Login >>>> >>>> (_) Use Local Server >>>> (_) Pick Server >>>> (_) Use this server ________________ >>>> >>>> The question is this: >>>> >>>> Should the EXE has the My.Settings and prepare the login form before >>>> doing a ShowDialog or can I do this in the Loginform class Load event >>>> by passing My.Settings to the constructor? >>>> >>>> For example: >>>> >>>> Public Class LoginForm >>>> >>>> Public UserSettings As My.Settings >>>> >>>> Private Sub LoginForm_Load( _ >>>> ByVal sender As Object, _ >>>> ByVal e As System.EventArgs) Handles Me.Load >>>> >>>> chkRemember.Checked = UserSettings.UseRemember <-- invalid >>>> chkAutoLogin.Checked = UserSettings.UseAutoLogin <-- invalid >>>> etc >>>> ... >>>> End Sub >>>> End Class >>>> >>>> The problem is that compiler issues the error: >>>> >>>> error BC30909: 'UserSettings' cannot expose type 'My.MySettings' >>>> outside the project through class 'LoginForm'. >>>> >>>> Of course, I can do this outside the form or maybe use properties from >>>> outside the form. >>>> >>>> Is that the way or is there another method? >>>> >>>> Thanks >>>> >>>> -- >>>> >>> >> >> > and I know that you have helped lots of people here including me but I think it is time to stop being the police of the newgroup and the person who color all comments with quotes that we just don't get. I will play traffic cop for a second and ask that if you don't know the answer or don't know what is being asked then say nothing. LS It works like what in VB6?
Show quoteHide quote "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message news:%23uQVxDb5JHA.1420@TK2MSFTNGP04.phx.gbl... > Mike, > > The my.Settings is build to make a bridge between VB6 users and Net > > It works like VB6 > It works like what in VB6? You don't need to instance an object to use this, it is completely shared.Some VB6 users showed that they did not understood the difference between a class and an object. Cor So what you meant to say was "Do not instantiate the My.Settings object or
refer to it via a variable. It's a shared object so you can reference it directly by its class name." The reference to VB6 was irrelevant. Show quoteHide quote "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message news:%23hNn9mm5JHA.6136@TK2MSFTNGP03.phx.gbl... >> It works like what in VB6? > > You don't need to instance an object to use this, it is completely shared. > > Some VB6 users showed that they did not understood the difference between > a class and an object. > > Cor > The closest i come in my memory to the my.settings in VB6 is INI but this
is so much more low level that it is like comparing a Steak with an Apple :-) MichelShow quoteHide quote "James Hahn" <jh***@yahoo.com> schreef in bericht news:%23vx26Nn5JHA.3860@TK2MSFTNGP05.phx.gbl... > So what you meant to say was "Do not instantiate the My.Settings object or > refer to it via a variable. It's a shared object so you can reference it > directly by its class name." > > The reference to VB6 was irrelevant. > > "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message > news:%23hNn9mm5JHA.6136@TK2MSFTNGP03.phx.gbl... >>> It works like what in VB6? >> >> You don't need to instance an object to use this, it is completely >> shared. >> >> Some VB6 users showed that they did not understood the difference between >> a class and an object. >> >> Cor >> > Michel,
Can you point me on the sentence where I said that it "was" in VB6. It is exactly like comparing a steak and an apple, it is not about what it is, it is how about you eat it. Although that was probably not what you meant. Cor Show quoteHide quote "Michel Posseth [MCP]" <m***@posseth.com> wrote in message news:1E0C04FF-9DF7-4BB8-BFAA-E72FCF3DBC36@microsoft.com... > The closest i come in my memory to the my.settings in VB6 is INI but > this is so much more low level that it is like comparing a Steak with an > Apple :-) > > Michel > > > > "James Hahn" <jh***@yahoo.com> schreef in bericht > news:%23vx26Nn5JHA.3860@TK2MSFTNGP05.phx.gbl... >> So what you meant to say was "Do not instantiate the My.Settings object >> or refer to it via a variable. It's a shared object so you can reference >> it directly by its class name." >> >> The reference to VB6 was irrelevant. >> >> "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message >> news:%23hNn9mm5JHA.6136@TK2MSFTNGP03.phx.gbl... >>>> It works like what in VB6? >>> >>> You don't need to instance an object to use this, it is completely >>> shared. >>> >>> Some VB6 users showed that they did not understood the difference >>> between a class and an object. >>> >>> Cor >>> >> > Huh ???
You said an i quote "It works like VB6" refering to the my.settings class wich you later in your replies upgraded to the whole my namespace if you feel this is wrong then reread what you wrote or correct me if i am wrong . Fact is that VB6 does not have a counterpart for my.settings and another fact is that the My namespace is a language enhancement introduced in the VB 2005 language library and is meant as a library of framework shortcuts My Namespace Visual Basic .Net 2005 introduced the My Namespace . In short the My namespace is a collection of shortcuts to a variety of classes in the framework . It offers mostly a single line reference to tasks that would otherwise take multiple lines of code to acomplish the same result . The my namespace offers the following classes Application, Computer, User, Forms, Resources, and Settings So my whole reaction was triggered about the fact that you told the TS that my.settings works like VB6 You know that i call myself a VB developer and for me the love i feel towards the Visual Basic language is not limited to the .Net or Legacy stigma . So how do you see this <VB 6> Option Explicit Private Declare Function WritePrivateProfileString Lib "kernel32" _ Alias "WritePrivateProfileStringA" _ (ByVal lpApplicationName As String, _ ByVal lpKeyName As Any, _ ByVal lpString As Any, _ ByVal lpFileName As String) As Long Private Declare Function GetPrivateProfileString Lib "kernel32" _ Alias "GetPrivateProfileStringA" _ (ByVal lpApplicationName As String, _ ByVal lpKeyName As Any, _ ByVal lpDefault As String, _ ByVal lpReturnedString As String, _ ByVal nSize As Long, _ ByVal lpFileName As String) As Long Public Function INIWrite(sSection As String, sKeyName As String, sNewString As String, sINIFileName As String) As Boolean Call WritePrivateProfileString(sSection, sKeyName, sNewString, sINIFileName) INIWrite = (Err.Number = 0) End Function Public Function INIRead(sSection As String, sKeyName As String, sINIFileName As String) As String Dim sRet As String sRet = String(255, Chr(0)) INIRead = Left(sRet, GetPrivateProfileString(sSection, ByVal sKeyName, "", sRet, Len(sRet), sINIFileName)) End Function compared to <VB.Net> My.Settings. as beeing a legacy from the above and therefore introduced in the my namespace IMHO : the my namespace is there to ensure that VB has a headstart on RAD in contradiction to the other .Net languages and has nothing to do with VB legacy at all ( as VB is always targeted to RAD developers by MS (Legacy and .Net )) Anyone who is stating the opposite is probably misinformed ( does not know VB6 and can thus not make the right conclusion when a VB.Net basher is filling the NG with these trolls ) or has access to knowledge i do not have however also opinions might change in time . I try to get the facts straight and base my opinion on that . regards Michel Show quoteHide quote "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> schreef in bericht news:e$UkLbn5JHA.6136@TK2MSFTNGP03.phx.gbl... > Michel, > > Can you point me on the sentence where I said that it "was" in VB6. > > It is exactly like comparing a steak and an apple, it is not about what it > is, it is how about you eat it. > > Although that was probably not what you meant. > > Cor > > "Michel Posseth [MCP]" <m***@posseth.com> wrote in message > news:1E0C04FF-9DF7-4BB8-BFAA-E72FCF3DBC36@microsoft.com... >> The closest i come in my memory to the my.settings in VB6 is INI but >> this is so much more low level that it is like comparing a Steak with an >> Apple :-) >> >> Michel >> >> >> >> "James Hahn" <jh***@yahoo.com> schreef in bericht >> news:%23vx26Nn5JHA.3860@TK2MSFTNGP05.phx.gbl... >>> So what you meant to say was "Do not instantiate the My.Settings object >>> or refer to it via a variable. It's a shared object so you can reference >>> it directly by its class name." >>> >>> The reference to VB6 was irrelevant. >>> >>> "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message >>> news:%23hNn9mm5JHA.6136@TK2MSFTNGP03.phx.gbl... >>>>> It works like what in VB6? >>>> >>>> You don't need to instance an object to use this, it is completely >>>> shared. >>>> >>>> Some VB6 users showed that they did not understood the difference >>>> between a class and an object. >>>> >>>> Cor >>>> >>> >> > Michel,
With "it works like VB6" I did never mean "it works like in VB6". I know that it is easy to use, however persons here busy with VB Net from 2002 where not really happy with it. It is not really OOP but using classic programming and therefore makes from VB Net a little bit as it was in VB6 In those days there were many discussions in the dotnet newsgroups if VB Net was a real mature OOP program language. But who cares today, those discussions are over. It has standard no counterparts in the other managed languages and it seems that it is as well not wanted in those. Cor Show quoteHide quote "Michel Posseth [MCP]" <M***@posseth.com> wrote in message news:%23HEIzmt5JHA.5180@TK2MSFTNGP04.phx.gbl... > > Huh ??? > > You said an i quote "It works like VB6" refering to the my.settings class > wich you later in your replies upgraded to the whole my namespace if you > feel this is wrong then reread what you wrote or correct me if i am wrong > . > > Fact is that VB6 does not have a counterpart for my.settings and another > fact is that the My namespace is a language enhancement introduced in the > VB 2005 language library and is meant as a library of framework shortcuts > > My Namespace > Visual Basic .Net 2005 introduced the My Namespace . In short the My > namespace is a collection of shortcuts to a variety of classes in the > framework . It offers mostly a single line reference to tasks that would > otherwise take multiple lines of code to acomplish the same result . The > my namespace offers the following classes Application, Computer, User, > Forms, Resources, and Settings > > So my whole reaction was triggered about the fact that you told the TS > that my.settings works like VB6 You know that i call myself a VB developer > and for me the love i feel towards the Visual Basic language is not > limited to the .Net or Legacy stigma . > > So how do you see this > > <VB 6> > > Option Explicit > > Private Declare Function WritePrivateProfileString Lib "kernel32" _ > Alias "WritePrivateProfileStringA" _ > (ByVal lpApplicationName As String, _ > ByVal lpKeyName As Any, _ > ByVal lpString As Any, _ > ByVal lpFileName As String) As Long > > Private Declare Function GetPrivateProfileString Lib "kernel32" _ > Alias "GetPrivateProfileStringA" _ > (ByVal lpApplicationName As String, _ > ByVal lpKeyName As Any, _ > ByVal lpDefault As String, _ > ByVal lpReturnedString As String, _ > ByVal nSize As Long, _ > ByVal lpFileName As String) As Long > > Public Function INIWrite(sSection As String, sKeyName As String, > sNewString As String, sINIFileName As String) As Boolean > > Call WritePrivateProfileString(sSection, sKeyName, sNewString, > sINIFileName) > INIWrite = (Err.Number = 0) > End Function > > Public Function INIRead(sSection As String, sKeyName As String, > sINIFileName As String) As String > Dim sRet As String > > sRet = String(255, Chr(0)) > INIRead = Left(sRet, GetPrivateProfileString(sSection, ByVal sKeyName, > "", sRet, Len(sRet), sINIFileName)) > End Function > > compared to > > <VB.Net> > > My.Settings. as beeing a legacy from the above and therefore > introduced in the my namespace > > IMHO : the my namespace is there to ensure that VB has a headstart on RAD > in contradiction to the other .Net languages > and has nothing to do with VB legacy at all ( as VB is always targeted to > RAD developers by MS (Legacy and .Net )) > > Anyone who is stating the opposite is probably misinformed ( does not > know VB6 and can thus not make the right conclusion when a VB.Net basher > is filling the NG with these trolls ) or has access to knowledge i do not > have however also opinions might change in time . > > I try to get the facts straight and base my opinion on that . > > regards > > Michel > > > > > > > > > > > > > > > > > > "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> schreef in bericht > news:e$UkLbn5JHA.6136@TK2MSFTNGP03.phx.gbl... >> Michel, >> >> Can you point me on the sentence where I said that it "was" in VB6. >> >> It is exactly like comparing a steak and an apple, it is not about what >> it is, it is how about you eat it. >> >> Although that was probably not what you meant. >> >> Cor >> >> "Michel Posseth [MCP]" <m***@posseth.com> wrote in message >> news:1E0C04FF-9DF7-4BB8-BFAA-E72FCF3DBC36@microsoft.com... >>> The closest i come in my memory to the my.settings in VB6 is INI but >>> this is so much more low level that it is like comparing a Steak with >>> an Apple :-) >>> >>> Michel >>> >>> >>> >>> "James Hahn" <jh***@yahoo.com> schreef in bericht >>> news:%23vx26Nn5JHA.3860@TK2MSFTNGP05.phx.gbl... >>>> So what you meant to say was "Do not instantiate the My.Settings object >>>> or refer to it via a variable. It's a shared object so you can >>>> reference it directly by its class name." >>>> >>>> The reference to VB6 was irrelevant. >>>> >>>> "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message >>>> news:%23hNn9mm5JHA.6136@TK2MSFTNGP03.phx.gbl... >>>>>> It works like what in VB6? >>>>> >>>>> You don't need to instance an object to use this, it is completely >>>>> shared. >>>>> >>>>> Some VB6 users showed that they did not understood the difference >>>>> between a class and an object. >>>>> >>>>> Cor >>>>> >>>> >>> >> > > Cor Ligthert[MVP] wrote:
Show quoteHide quote > Michel, Not sure how this correlates to using My.Settings between a EXE and DLL?> > With "it works like VB6" I did never mean "it works like in VB6". > > I know that it is easy to use, however persons here busy with VB Net > from 2002 where not really happy with it. > > It is not really OOP but using classic programming and therefore makes > from VB Net a little bit as it was in VB6 > > In those days there were many discussions in the dotnet newsgroups if VB > Net was a real mature OOP program language. > > But who cares today, those discussions are over. > > It has standard no counterparts in the other managed languages and it > seems that it is as well not wanted in those. > > Cor I guess maybe I do, but we are talking VB.NET and not VB6. :-) In any case, my near final solution is: 1) Create the project settings in the DLL windows form 2) Use PropertyBinding to bind the form fields with the DLL my.settings namespace 3) Used a Partial Class with Nested class with a default property to access My.Settings Partial Class WildcatLoginForm Public Settings As New LoginSettings Public Class LoginSettings Default Property Self(ByVal name As String) As Object Get Return My.Settings(name) End Get Set(ByVal value As Object) My.Settings(name) = value End Set End Property End Class End Class Probably more direct ways but this reduced the code avoiding to create a property for each field and the EXE now has access to the fields using properties: Session = New WildcatLoginForm Session.Settings("name") = value Before this last version, where I add each field as a get/set property which I might go back to once I learn how to use ApplicationSettingsBase. Its all good Now. :-) -- Mike
I use this in my projects this gives you the ability to ship dll specific config files with your project Imports System.Configuration Namespace My Partial Friend NotInheritable Class MySettings Private DllSettings As ClientSettingsSection Private DllConfigDoesNotExist As Boolean Default Public Overrides Property Item(ByVal propertyName As String) As Object Get Dim oValue As Object = Nothing Try 'If the .dll.config file has already been loaded, use it to obtain the value... If DllSettings IsNot Nothing Then oValue = DllSettings.Settings.Get(propertyName).Value.ValueXml.InnerXml ElseIf Not DllConfigDoesNotExist Then If Me.LoadDllConfigFile() Then oValue = DllSettings.Settings.Get(propertyName).Value.ValueXml.InnerXml End If End If Catch ex As Exception End Try Try If oValue Is Nothing Then oValue = MyBase.Item(propertyName) End If Catch ex As Exception End Try Return oValue End Get Set(ByVal value As Object) MyBase.Item(propertyName) = value End Set End Property Private Function LoadDllConfigFile() As Boolean Dim bDllConfigLoaded As Boolean = False Dim cfgDll As System.Configuration.Configuration Dim cfmDllCfg As New ExeConfigurationFileMap() Dim sAssemblyPath As String = Reflection.Assembly.GetExecutingAssembly().Location Dim strNamespace As String = GetType(MySettings).FullName strNamespace = strNamespace.Substring(0, strNamespace.IndexOf("."c)) cfmDllCfg.ExeConfigFilename = sAssemblyPath & ".config" Try cfgDll = ConfigurationManager.OpenMappedExeConfiguration(cfmDllCfg, ConfigurationUserLevel.None) Dim csgApplicationSettings As ConfigurationSectionGroup = cfgDll.GetSectionGroup("applicationSettings") Me.DllSettings = DirectCast(csgApplicationSettings.Sections(strNamespace & ".My.MySettings"), ClientSettingsSection) bDllConfigLoaded = True Catch ex As Exception 'bestaat niet DllConfigDoesNotExist = True End Try Return bDllConfigLoaded End Function End Class End Namespace Show quoteHide quote "Mike" <unkn***@unknown.tv> schreef in bericht news:uKCILt15JHA.1096@TK2MSFTNGP06.phx.gbl... > Cor Ligthert[MVP] wrote: >> Michel, >> >> With "it works like VB6" I did never mean "it works like in VB6". >> >> I know that it is easy to use, however persons here busy with VB Net from >> 2002 where not really happy with it. >> >> It is not really OOP but using classic programming and therefore makes >> from VB Net a little bit as it was in VB6 >> >> In those days there were many discussions in the dotnet newsgroups if VB >> Net was a real mature OOP program language. >> >> But who cares today, those discussions are over. >> >> It has standard no counterparts in the other managed languages and it >> seems that it is as well not wanted in those. >> >> Cor > > Not sure how this correlates to using My.Settings between a EXE and DLL? > > I guess maybe I do, but we are talking VB.NET and not VB6. :-) > > In any case, my near final solution is: > > 1) Create the project settings in the DLL windows form > > 2) Use PropertyBinding to bind the form fields with > the DLL my.settings namespace > > 3) Used a Partial Class with Nested class with a default > property to access My.Settings > > Partial Class WildcatLoginForm > Public Settings As New LoginSettings > Public Class LoginSettings > Default Property Self(ByVal name As String) As Object > Get > Return My.Settings(name) > End Get > Set(ByVal value As Object) > My.Settings(name) = value > End Set > End Property > End Class > End Class > > Probably more direct ways but this reduced the code avoiding to create a > property for each field and the EXE now has access to the fields using > properties: > > Session = New WildcatLoginForm > Session.Settings("name") = value > > Before this last version, where I add each field as a get/set property > which I might go back to once I learn how to use ApplicationSettingsBase. > > Its all good Now. :-) > > -- > I was a bit to quick with posting the reply :-)
usage : set a reference to system.configuration , include the code file in your projects now these projects can aquire the settings from there own config file if called by a exe this was the bit of extra coding i was refering to in my initail answer :-) HTH Michel Show quoteHide quote "Michel Posseth [MCP]" <M***@posseth.com> schreef in bericht news:uWoeL215JHA.1716@TK2MSFTNGP03.phx.gbl... > Mike > > I use this in my projects this gives you the ability to ship dll specific > config files with your project > > > Imports System.Configuration > Namespace My > Partial Friend NotInheritable Class MySettings > Private DllSettings As ClientSettingsSection > Private DllConfigDoesNotExist As Boolean > Default Public Overrides Property Item(ByVal propertyName As > String) As Object > Get > Dim oValue As Object = Nothing > Try > 'If the .dll.config file has already been loaded, use > it to obtain the value... > If DllSettings IsNot Nothing Then > oValue = > DllSettings.Settings.Get(propertyName).Value.ValueXml.InnerXml > ElseIf Not DllConfigDoesNotExist Then > If Me.LoadDllConfigFile() Then > oValue = > DllSettings.Settings.Get(propertyName).Value.ValueXml.InnerXml > End If > End If > Catch ex As Exception > End Try > Try > If oValue Is Nothing Then > oValue = MyBase.Item(propertyName) > End If > Catch ex As Exception > End Try > Return oValue > End Get > Set(ByVal value As Object) > MyBase.Item(propertyName) = value > End Set > End Property > Private Function LoadDllConfigFile() As Boolean > Dim bDllConfigLoaded As Boolean = False > Dim cfgDll As System.Configuration.Configuration > Dim cfmDllCfg As New ExeConfigurationFileMap() > > Dim sAssemblyPath As String = > Reflection.Assembly.GetExecutingAssembly().Location > > Dim strNamespace As String = GetType(MySettings).FullName > strNamespace = strNamespace.Substring(0, > strNamespace.IndexOf("."c)) > > > cfmDllCfg.ExeConfigFilename = sAssemblyPath & ".config" > Try > > cfgDll = > ConfigurationManager.OpenMappedExeConfiguration(cfmDllCfg, > ConfigurationUserLevel.None) > > Dim csgApplicationSettings As ConfigurationSectionGroup = > cfgDll.GetSectionGroup("applicationSettings") > Me.DllSettings = > DirectCast(csgApplicationSettings.Sections(strNamespace & > ".My.MySettings"), ClientSettingsSection) > bDllConfigLoaded = True > > Catch ex As Exception > > 'bestaat niet > DllConfigDoesNotExist = True > > End Try > Return bDllConfigLoaded > > End Function > > End Class > > End Namespace > > > > > > > > > "Mike" <unkn***@unknown.tv> schreef in bericht > news:uKCILt15JHA.1096@TK2MSFTNGP06.phx.gbl... >> Cor Ligthert[MVP] wrote: >>> Michel, >>> >>> With "it works like VB6" I did never mean "it works like in VB6". >>> >>> I know that it is easy to use, however persons here busy with VB Net >>> from 2002 where not really happy with it. >>> >>> It is not really OOP but using classic programming and therefore makes >>> from VB Net a little bit as it was in VB6 >>> >>> In those days there were many discussions in the dotnet newsgroups if VB >>> Net was a real mature OOP program language. >>> >>> But who cares today, those discussions are over. >>> >>> It has standard no counterparts in the other managed languages and it >>> seems that it is as well not wanted in those. >>> >>> Cor >> >> Not sure how this correlates to using My.Settings between a EXE and DLL? >> >> I guess maybe I do, but we are talking VB.NET and not VB6. :-) >> >> In any case, my near final solution is: >> >> 1) Create the project settings in the DLL windows form >> >> 2) Use PropertyBinding to bind the form fields with >> the DLL my.settings namespace >> >> 3) Used a Partial Class with Nested class with a default >> property to access My.Settings >> >> Partial Class WildcatLoginForm >> Public Settings As New LoginSettings >> Public Class LoginSettings >> Default Property Self(ByVal name As String) As Object >> Get >> Return My.Settings(name) >> End Get >> Set(ByVal value As Object) >> My.Settings(name) = value >> End Set >> End Property >> End Class >> End Class >> >> Probably more direct ways but this reduced the code avoiding to create a >> property for each field and the EXE now has access to the fields using >> properties: >> >> Session = New WildcatLoginForm >> Session.Settings("name") = value >> >> Before this last version, where I add each field as a get/set property >> which I might go back to once I learn how to use >> ApplicationSettingsBase. >> >> Its all good Now. :-) >> >> -- >> > > Thanks. I plan to see how it works in the next few days. :-)
Michel Posseth [MCP] wrote: Show quoteHide quote > Mike > > I use this in my projects this gives you the ability to ship dll specific > config files with your project > > > Imports System.Configuration > Namespace My > Partial Friend NotInheritable Class MySettings > Private DllSettings As ClientSettingsSection > Private DllConfigDoesNotExist As Boolean > Default Public Overrides Property Item(ByVal propertyName As String) > As Object > Get > Dim oValue As Object = Nothing > Try > 'If the .dll.config file has already been loaded, use it > to obtain the value... > If DllSettings IsNot Nothing Then > oValue = > DllSettings.Settings.Get(propertyName).Value.ValueXml.InnerXml > ElseIf Not DllConfigDoesNotExist Then > If Me.LoadDllConfigFile() Then > oValue = > DllSettings.Settings.Get(propertyName).Value.ValueXml.InnerXml > End If > End If > Catch ex As Exception > End Try > Try > If oValue Is Nothing Then > oValue = MyBase.Item(propertyName) > End If > Catch ex As Exception > End Try > Return oValue > End Get > Set(ByVal value As Object) > MyBase.Item(propertyName) = value > End Set > End Property > Private Function LoadDllConfigFile() As Boolean > Dim bDllConfigLoaded As Boolean = False > Dim cfgDll As System.Configuration.Configuration > Dim cfmDllCfg As New ExeConfigurationFileMap() > > Dim sAssemblyPath As String = > Reflection.Assembly.GetExecutingAssembly().Location > > Dim strNamespace As String = GetType(MySettings).FullName > strNamespace = strNamespace.Substring(0, > strNamespace.IndexOf("."c)) > > > cfmDllCfg.ExeConfigFilename = sAssemblyPath & ".config" > Try > > cfgDll = > ConfigurationManager.OpenMappedExeConfiguration(cfmDllCfg, > ConfigurationUserLevel.None) > > Dim csgApplicationSettings As ConfigurationSectionGroup = > cfgDll.GetSectionGroup("applicationSettings") > Me.DllSettings = > DirectCast(csgApplicationSettings.Sections(strNamespace & ".My.MySettings"), > ClientSettingsSection) > bDllConfigLoaded = True > > Catch ex As Exception > > 'bestaat niet > DllConfigDoesNotExist = True > > End Try > Return bDllConfigLoaded > > End Function > > End Class > > End Namespace > > > > > > > > > "Mike" <unkn***@unknown.tv> schreef in bericht > news:uKCILt15JHA.1096@TK2MSFTNGP06.phx.gbl... >> Cor Ligthert[MVP] wrote: >>> Michel, >>> >>> With "it works like VB6" I did never mean "it works like in VB6". >>> >>> I know that it is easy to use, however persons here busy with VB Net from >>> 2002 where not really happy with it. >>> >>> It is not really OOP but using classic programming and therefore makes >>> from VB Net a little bit as it was in VB6 >>> >>> In those days there were many discussions in the dotnet newsgroups if VB >>> Net was a real mature OOP program language. >>> >>> But who cares today, those discussions are over. >>> >>> It has standard no counterparts in the other managed languages and it >>> seems that it is as well not wanted in those. >>> >>> Cor >> Not sure how this correlates to using My.Settings between a EXE and DLL? >> >> I guess maybe I do, but we are talking VB.NET and not VB6. :-) >> >> In any case, my near final solution is: >> >> 1) Create the project settings in the DLL windows form >> >> 2) Use PropertyBinding to bind the form fields with >> the DLL my.settings namespace >> >> 3) Used a Partial Class with Nested class with a default >> property to access My.Settings >> >> Partial Class WildcatLoginForm >> Public Settings As New LoginSettings >> Public Class LoginSettings >> Default Property Self(ByVal name As String) As Object >> Get >> Return My.Settings(name) >> End Get >> Set(ByVal value As Object) >> My.Settings(name) = value >> End Set >> End Property >> End Class >> End Class >> >> Probably more direct ways but this reduced the code avoiding to create a >> property for each field and the EXE now has access to the fields using >> properties: >> >> Session = New WildcatLoginForm >> Session.Settings("name") = value >> >> Before this last version, where I add each field as a get/set property >> which I might go back to once I learn how to use ApplicationSettingsBase. >> >> Its all good Now. :-) >> >> -- >> > > "James Hahn" <jh***@yahoo.com> wrote in message And please read my original reply not what is stated here by others.news:%23vx26Nn5JHA.3860@TK2MSFTNGP05.phx.gbl... > So what you meant to say was "Do not instantiate the My.Settings object or > refer to it via a variable. It's a shared object so you can reference it > directly by its class name." > > The reference to VB6 was irrelevant. > Why? It is expressly for that reason not in C# or in managed C++ or in managed F# Cor
Show quote
Hide quote
"Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message I have not commented on anything other then your posts. You made two news:ukOCpXn5JHA.2456@TK2MSFTNGP02.phx.gbl... > > "James Hahn" <jh***@yahoo.com> wrote in message > news:%23vx26Nn5JHA.3860@TK2MSFTNGP05.phx.gbl... >> So what you meant to say was "Do not instantiate the My.Settings object >> or refer to it via a variable. It's a shared object so you can reference >> it directly by its class name." >> >> The reference to VB6 was irrelevant. >> > Why? > > And please read my original reply not what is stated here by others. > statemenets: "The my.Settings is build to make a bridge between VB6 users and Net" I have no idea what that means and I ignored it. "It works like VB6" I assumed that this referred to the "my.Settings" reference in the above line, and I asked "It works like what in VB6?" because I didn't know of anything in VB6 that worked in a way that was like My.Settings. If this statement was meant to be helpful, why not let us in one the secret of which part of VB6 works like My.Settings? You responded with: "You don't need to instance an object to use this, it is completely shared. "Some VB6 users showed that they did not understood the difference between a class and an object." I attempted a translation of that first statement (which I am happy to have corected if I got it wrong) and I noted that the second comment was irrelevant, which it is. You now tell me that: "It is expressly for that reason not in C# or in managed C++ or in managed F#" I think you are saying that the My.Settings functionality does not exist in those languages because some VB6 users cannot distinguish between a class and an object (which I read as "between a class and an instance of a class") which I suppose derives from some inside knowledge you have of how the product design teams think. Regardless, it is just as irrelevant as your orignal reference to VB6. If you are trying to make some point that assists OP in resolving the issue, please do so without this political grandstanding. James Hahn wrote:
> "It works like VB6" Like I mentioned in my response to Cor's "it works like VB6"> I assumed that this referred to the "my.Settings" reference in the above > line, and I asked > "It works like what in VB6?" > because I didn't know of anything in VB6 that worked in a way that was > like My.Settings. If this statement was meant to be helpful, why not let > us in one the secret of which part of VB6 works like My.Settings? I never used this at the VB6 level... what I did used in the past for our only VB6-based add-on product was using the Win32 Private Profile API in INI mode. So when Cor stated that, what resurfaced in my mind was the possible connection to the MSDN documentation statement that My.Settings was a "Compatibility module" and that was probably what Cor meant. i.e. My.Settings replaces PrivateProfile with an XML storage method and/or VB.NET had a similar MFC application class that wraps the Private Profiles API. But the usage is different and the question pertain to what amounted in my mind to sharing the same process "My" namespace between the EXE and DLL. (See technical note below). In the final analysis, is that the same process user's local setting storage location is used, however, the section used for each is separated: So what you end up having is: <?xml version="1.0" encoding="utf-8"?> <configuration> <configSections> <sectionGroup name="userSettings" ... > <section name="YOUR-PROCESS-EXE.My.MySettings" ... /> <section name="YOUR-DLL.My.MySettings" ... /> </sectionGroup> </configSections> <userSettings> <YOUR-PROCESS-EXE.My.MySettings> ... settings names and values ... </YOUR-PROCESS-EXE.My.MySettings> <YOUR-DLL.My.MySettings> ... settings names and values ... </YOUR-DLL.My.MySettings> </userSettings> </configuration> and this is stored (in User Scope): %USERPROFILE%\Local Settings\Application Data \COMPANY_NAME\YOUR-PROCESS-EXE_GUID\VERSION user.config Regarding the Sharing of namespace: Ok, this is where I probably "over thought" that VB.NET provided inherent support for Global Shared Memory of "MY" between all .NET assemblies. My suspicion that it does for its own .NET purposes. But at the application level, you have to role your own and this is the same in all other languages. So if you wanted to share memory created by a DLL or EXE you either have to compile the same RDATA segment name or used a memory map using WIN32 API functions: CreateFileMapping() (server uses this) OpenFileMapping() (client uses this) MapViewOfFile() (server/client uses this) In other words, I thought "My" with its nested objects: My.Application My.Computer My.Settings My.User was a GLOBAL shared memory map that allowed the EXE and her .NET dlls to shared this "namespace" At this point, I get the idea that it might be sharing, but there are other things you need to prepare (security wise) to allow it to happen. But for the settings, it uses the same file, but the sections are different. -- Mike wrote:
Show quoteHide quote > There are probably all kinds of implementations ideas going on here, > In other words, I thought "My" with its nested objects: > > My.Application > My.Computer > My.Settings > My.User > > was a GLOBAL shared memory map that allowed the EXE and her .NET dlls to > shared this "namespace" > > At this point, I get the idea that it might be sharing, but there are > other things you need to prepare (security wise) to allow it to happen. > But for the settings, it uses the same file, but the sections are > different. but the purpose of single sourcing your code, I see some architecture notes here that is helpful: Application Settings Architecture http://msdn.microsoft.com/en-us/library/8eyb2ct1.aspx I added the example code into my DLL class: Public Class MyUserSettings Inherits ApplicationSettingsBase <UserScopedSetting()> _ <DefaultSettingValue("True")> _ Public Property UseAutoLogin() As Boolean Get return Me("UseAutoLogin") End Get Set(ByVal value As Boolean) Me("UseAutoLogin") = value End Set End Property End Class And now I can use this a common class in the process itself. I am currently reading the section on "Settings Persistence" regarding the SettingsProvider. Note: I already have a working solution so all this is more exploring whats there. For example, I had manually add properties to set/get the form fields but now I see it was already provided via: Property Binding To provide access to the EXE, I had created Get/Set properties (like above) but I did that in the Form partial class. With Property Binding I can now remove this redundant code. But I see this does not expose the property to the EXE so I think I prefer to keep the properties I added but this time add them to an inherited ApplicationSettingBase class so I can get access other class features, like Save() which was also manually added to the form partial class. Ideally, what would useful and I believe a natural logic and declarative (layman coding) for RAD developers is extension to the My.Application object like My.Application.Settings That way it can be used by the application DLLs. Anyway.... <g> I don't understand the reference to shared memeory. In .Net all
communication between the EXE and DLL will be by properties that each exposes or parameters passed in methods (including constructors). You may have been misled by the reference to VB6 - My.Settings is not even vaguely similar to anything in VB6, and it is certainly not global.. I would not contemplate using some feature of the My namespace to provide a form of shared access. There just doesn't seem to be any point, even if you could do it. The DLL is going to be invoked by the application - it should not need to look back into application or user settings for its parameters - they should be passed in whatever call invoked the function in the DLL, or by properties of the DLL that were set by the applcation before it invoked the function. That's the .Net way. Show quoteHide quote "Mike" <unkn***@unknown.tv> wrote in message news:eLB7HFz5JHA.4632@TK2MSFTNGP02.phx.gbl... > Mike wrote: >> >> In other words, I thought "My" with its nested objects: >> >> My.Application >> My.Computer >> My.Settings >> My.User >> >> was a GLOBAL shared memory map that allowed the EXE and her .NET dlls to >> shared this "namespace" >> >> At this point, I get the idea that it might be sharing, but there are >> other things you need to prepare (security wise) to allow it to happen. >> But for the settings, it uses the same file, but the sections are >> different. > > There are probably all kinds of implementations ideas going on here, but > the purpose of single sourcing your code, I see some architecture notes > here that is helpful: > > Application Settings Architecture > http://msdn.microsoft.com/en-us/library/8eyb2ct1.aspx > > I added the example code into my DLL class: > > Public Class MyUserSettings > Inherits ApplicationSettingsBase > <UserScopedSetting()> _ > <DefaultSettingValue("True")> _ > Public Property UseAutoLogin() As Boolean > Get > return Me("UseAutoLogin") > End Get > Set(ByVal value As Boolean) > Me("UseAutoLogin") = value > End Set > End Property > End Class > > And now I can use this a common class in the process itself. I am > currently reading the section on "Settings Persistence" regarding the > SettingsProvider. > > Note: I already have a working solution so all this is more exploring > whats there. For example, I had manually add properties to set/get the > form fields but now I see it was already provided via: > > Property Binding > > To provide access to the EXE, I had created Get/Set properties (like > above) but I did that in the Form partial class. With Property Binding I > can now remove this redundant code. But I see this does not expose the > property to the EXE so I think I prefer to keep the properties I added but > this time add them to an inherited ApplicationSettingBase class so I can > get access other class features, like Save() which was also manually added > to the form partial class. > > Ideally, what would useful and I believe a natural logic and declarative > (layman coding) for RAD developers is extension to the My.Application > object like > > My.Application.Settings > > That way it can be used by the application DLLs. > > Anyway.... <g> James,
> You may have been misled by the reference to VB6 - My.Settings is not even You mean you can use it everywhere in an application but it is not global > vaguely similar to anything in VB6, and it is certainly not global.. usable. Ah now I understand a lot. Cor That's correct. The My.Settings values are available anywhere in the
application, but they are specific to the application (and the user) and are not available globally, for instance from the DLL. That's why OP had to take special steps to access the application My.Settings from the DLL (which, IMHO, would have been better done by exposing properties or passing parameters). You will find a good description of My.Settings in MSDN - you may wish to start here: http://msdn.microsoft.com/en-us/library/ms379611(VS.80).aspx Show quoteHide quote "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message news:ek7dQ2$5JHA.1416@TK2MSFTNGP04.phx.gbl... > James, > >> You may have been misled by the reference to VB6 - My.Settings is not >> even vaguely similar to anything in VB6, and it is certainly not global.. > > You mean you can use it everywhere in an application but it is not global > usable. > > Ah now I understand a lot. > > Cor James,
I wasn't misled by Cor. Whether My.Settings was "like" in VB6 or not was besides the point because it didn't answer the question. I clearly knew it wasn't the same, but I did give him the benefit of the doubt that it was like MFC ala CWinAPP application class, that uses private profile wrappers for INI or Registry storage depending on the mode you choose. But as others pointed out, importing the private profile functions would be necessary in VB6. The "ah ha" for me (and I am sure it would be for many) is that the storage is in the same file but different nodes (sections) in the XML document and it is stored under the user's application local setting folder - all by default using the LocalSettingsProvider. Once realized it was easy to self-contain the fields (as I wanted) in the default section for the DLL assembly and as I outlined they were exposed via a default property in the DLL class. It seems you skimmed over what I wrote :) Last small point, sure, its the .NET way, but in reality it is the .DLL way. :-) If anything to be gained, as I also noted, is a possible enhancement to allow a more declarative reference to a new object: My.Application.Settings <---- Process NameSpace Storage My.Settings <---- Current Assembly Namespace Storage That would be, in my opinion, "easier" for the RAD VB developers and would wrap the RoamingUser (initially viewed as a bad terminology as that has a specific meaning in other technologies) concept for configuration. -- Show quoteHide quoteJames Hahn wrote: > That's correct. The My.Settings values are available anywhere in the > application, but they are specific to the application (and the user) and > are not available globally, for instance from the DLL. That's why OP > had to take special steps to access the application My.Settings from the > DLL (which, IMHO, would have been better done by exposing properties or > passing parameters). You will find a good description of My.Settings in > MSDN - you may wish to start here: > http://msdn.microsoft.com/en-us/library/ms379611(VS.80).aspx > > "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message > news:ek7dQ2$5JHA.1416@TK2MSFTNGP04.phx.gbl... >> James, >> >>> You may have been misled by the reference to VB6 - My.Settings is not >>> even vaguely similar to anything in VB6, and it is certainly not >>> global.. >> >> You mean you can use it everywhere in an application but it is not >> global usable. >> >> Ah now I understand a lot. >> >> Cor > See my reply to Michel
Show quoteHide quote "James Hahn" <jh***@yahoo.com> wrote in message news:ezIwyTx5JHA.5728@TK2MSFTNGP03.phx.gbl... > "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message > news:ukOCpXn5JHA.2456@TK2MSFTNGP02.phx.gbl... >> >> "James Hahn" <jh***@yahoo.com> wrote in message >> news:%23vx26Nn5JHA.3860@TK2MSFTNGP05.phx.gbl... >>> So what you meant to say was "Do not instantiate the My.Settings object >>> or refer to it via a variable. It's a shared object so you can reference >>> it directly by its class name." >>> >>> The reference to VB6 was irrelevant. >>> >> Why? >> >> And please read my original reply not what is stated here by others. >> > > I have not commented on anything other then your posts. You made two > statemenets: > "The my.Settings is build to make a bridge between VB6 users and Net" > I have no idea what that means and I ignored it. > > "It works like VB6" > I assumed that this referred to the "my.Settings" reference in the above > line, and I asked > "It works like what in VB6?" > because I didn't know of anything in VB6 that worked in a way that was > like My.Settings. If this statement was meant to be helpful, why not let > us in one the secret of which part of VB6 works like My.Settings? > > You responded with: > "You don't need to instance an object to use this, it is completely > shared. > > "Some VB6 users showed that they did not understood the difference between > a > class and an object." > > I attempted a translation of that first statement (which I am happy to > have corected if I got it wrong) and I noted that the second comment was > irrelevant, which it is. > > You now tell me that: > > "It is expressly for that reason not in C# or in managed C++ or in managed > F#" > > I think you are saying that the My.Settings functionality does not exist > in those languages because some VB6 users cannot distinguish between a > class and an object (which I read as "between a class and an instance of a > class") which I suppose derives from some inside knowledge you have of how > the product design teams think. Regardless, it is just as irrelevant as > your orignal reference to VB6. If you are trying to make some point that > assists OP in resolving the issue, please do so without this political > grandstanding. "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message Some VB.Net users show that they don't know the difference between their news:%23hNn9mm5JHA.6136@TK2MSFTNGP03.phx.gbl... > Some VB6 users showed that they did not understood > the difference between a class and an object. arse and their elbow. Don't tar the many with the failings of the few. |
|||||||||||||||||||||||
Other interesting topics