My.Settings Questions

  • Thread starter Thread starter Mike
  • Start date Start date
M

Mike

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

--
 
Mike,

The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6

Cor
 
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.

--

Mike,

The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6

Cor


Mike said:
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
Click to expand...
Click to expand...
 
The my.Settings is build to make a bridge between VB6 users and Net
It works like VB6
Click to expand...


:-| 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 said:
Mike,

The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6

Cor


Mike said:
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
Click to expand...
Click to expand...
 
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 said:
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.

--

Mike,

The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6

Cor


Mike said:
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
Click to expand...
Click to expand...
Click to expand...
 
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 said:
The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6
Click to expand...


:-| 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 said:
Mike,

The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6

Cor


Mike said:
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
Click to expand...
Click to expand...
Click to expand...
 
Sorry but i have no idea what you are trying to tell , i am probably missing
something

Michel




Cor Ligthert said:
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 said:
The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6
Click to expand...


:-| 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 said:
Mike,

The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6

Cor


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
Click to expand...
Click to expand...
Click to expand...
 
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

--

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 said:
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.

--

Mike,

The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6

Cor


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
Click to expand...
Click to expand...
Click to expand...
 
Cor Ligthert said:
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 said:
The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6
Click to expand...


:-| 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 said:
Mike,

The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6

Cor


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
Click to expand...
Click to expand...

You know I have been listening to your off topic comments for quite a while
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
Click to expand...
 
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

Michel Posseth said:
Sorry but i have no idea what you are trying to tell , i am probably
missing something

Michel




Cor Ligthert said:
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 said:
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]" <[email protected]> schreef in bericht
Mike,

The my.Settings is build to make a bridge between VB6 users and Net

It works like VB6

Cor


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
Click to expand...
Click to expand...
Click to expand...
 
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.
 
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 said:
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.
Click to expand...
Why?

And please read my original reply not what is stated here by others.

It is expressly for that reason not in C# or in managed C++ or in managed F#

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
 
Michel [Michel Posseth], You show me a text which is
in my idea full of marketing sentences . . .
Click to expand...

That's very funny coming from you Ligthert. You're a marketing man's wet
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
 
Some VB6 users showed that they did not understood
the difference between a class and an object.
Click to expand...

Some VB.Net users show that they don't know the difference between their
arse and their elbow. Don't tar the many with the failings of the few.
 
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 said:
Why?

And please read my original reply not what is stated here by others.
Click to expand...

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.
 
Back
Top