Is there a replacement for Public memvars? 1

[IlyaRabyy]

Colleagues,

I've been working mostly in FPD/VFP for the last 25 years, till last summer.
I don't like global/public memvars (well, yeah!). VFP has system variable (object, actually) _VFP, which I used to avoid declaring public memvars,
something like

_VFP.AddProperty("glDevelop", (_VFP.StartMode == 0))

which I've been using to distinguish between IDE and EXE runs.
I did work (and even taught programming for 3 years in a college) in VB5-6 and developed commercial programs in VB4-6... till 2006. Never ever since.
I am working with a VB .NET program now, trying to create a new generation of it. And it has a shipload of Public memvars!
I do not want to add my own, hence my question:

Is there an equivalent in VB .NET 2012 to _VFP.StartMode? (Anything in Settings.Designer, maybe? Anywhere else?)

Please advise.

TIA!


Regards,

Ilya

 

[jebenson]

If all you want is to distinguish between IDE and EXE runs, what I do is set a command line argument in the project properties, then do a check to see if there are any command line arguments when the program starts. If there are, it's in the IDE. To do this:

Go to the PROJECT menu, then select "<project name> Properties"
Select the Debug tab on the left
Put any value (I usually use "1") in the "Command line arguments" box
Close properties and save

Use this code to determine if there are command line arguments:

If Environment.GetCommandLineArgs.Length > 1 Then
    'Run from the IDE
Else
    'Run from EXE
End If

I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson

Arrrr, mateys! Ye needs ta be preparin' yerselves fer Talk Like a Pirate Day!

 

[IlyaRabyy]

Arrr, matey, er answer's mighty good and made me think!
;-)
There is an Environment class in .NET after all!

I found it there:

https://docs.microsoft.com/en-us/dotnet/api/system.environment?view=netframework-4.8

- and was ready to ...
However, this humble one didn't find whether this Environment allows adding custom properties to it.

Methinks, matey, t's READ-ONLY kinda thingy...

Anyway, since it's Static class - it cannot be modified (e.g. there's no AddProperty() method), right?
Then I thought about subclassing it to a regular class programmatically, but it says there "This class cannot be inherited"... :-(

It seems to me that the only reasonable option to avoid declaring Public memvars (which is... ah-hemm... mildly put - not so much of a good programming practice) is to create a class (also Static, maybe?) in a separate module? And "import" it into other modules in a project/solution?
"Whaddya think of that?" (Ian Gillan in "Anyone's Daughter", "Fireball", 1971)


Regards,

Ilya

 

[jebenson]

Environment is not read-only. Use Environment.SetEnvironmentVariable(variable As String, value As String) to set an Environment variable. Use Environment.GetEnvironmentVariable(variable As String) to retrieve.

I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson

Arrrr, mateys! Ye needs ta be preparin' yerselves fer Talk Like a Pirate Day!

 

[strongm]

Perhaps you might want to investigate the ExpandoObject class ... then you can do something like (you'll need to do some reading as this requires certain Options settings that you might not be happy with):

[blue]        Dim fred As Object = New System.Dynamic.ExpandoObject
        fred.wombat = 5
        MsgBox(fred.wombat)[/blue]

(Although this is probably even worse than global variables - which frankly do have their role to play; it is purely dogma to try and avoid them completely)

 

[IlyaRabyy]

Thank you both, colleague J. E. Benson (hope I got it right?) and colleague Strong M. (hope I'm not too frivolous?)
Following your leads, I discovered method Environment.ExpandEnvironmentsVariables()!
I made a small Sub to display all the standard ones (and of course I had to "redact classified data" ;-) ) and added it to my "sandbox" program:

Now, does any of the above tells you whether this sub was run in VS IDE or within a compiled EXE?

Please review and advise!

TIA!



Regards,

Ilya

 

[strongm]

Let's just clarify - is your issue public variables, or determining if you are in the IDE or not?

 

[IlyaRabyy]

strongm (MIS)
28 Feb 20 23:23
Let's just clarify - is your issue public variables, or determining if you are in the IDE or not?"

Both.
Clarifications:

1. I worked for the last 30 years in FPD/VFP mostly (also VB from 1992 to 2006, and a bit of C# in 2005-2007), last 10 years - exclusively in VFP; VFP has "system" variable, _VFP, which is actually an object; this latter has StartMode() method, so _VFP.StartMode() returns 0 (zero) if this command was issued in a code running in the IDE.
I hoped that a) VB acquired something similar from .NET, and b) use it the way I got used to in VFP.

2. Besides that _VFP memvar, VFP also has _SCREEN "system" variable, also an object (a Form, actually, MDI, main VFP's screen), and it has AddProperty(cName,[uDefaultVal]) method (uDefaultVal is optional).
And, to avoid declaring a slew of PUBLIC memvars, I used this _SCREEN.AddProperty(glDevelop, (_VFP.StartMode()==0)).
The rest is obvious, I hope. But nonehteless, one example:
If it's IDE run - I need to restore all the settings (especially those of _SCREEN) which I had to modify at the start of my program I was testing in IDE, let alone RELEASE (discard) all the classlibs, objects, etc., which I instantiated with public memvars as handles;
But if it's EXE - no need to, VFP's run-time system DLL did all the "garbage collection".

Hope I've made myself clear(er)?

Regards,

Ilya

 

[strongm]

let me ask a slightly different question: what objection to public variables do you think that using _SCREEN or _VFP avoids?

As for the IDE - well, .net applications don't really run in the IDE. The IDE acts as a debugger to which a compiled build attaches. In which case the following tells you if you are running 'in' the IDE:

MsgBox(System.Diagnostics.Debugger.IsAttached)

 

[IlyaRabyy]

System.Diagnostics.Debugger.IsAttached - great! That's what I was after!
Thank you!
As for avoiding PUBLIC memvars by adding custom properties to _SCREEN (not to _VFP, BTW) - that was advice given to me by (IMS) Andy Kramek way-way back (in 2002... again, IMS). The reason was to avoid declaring a private or local memvar with the same name a public one, inadvertently. There's a difference between StartDir and _SCREEN.StartDir, isn't there? ;-)

Thank you again for your help, colleagues!

Issue's been resolved, case is being closed.


Regards,

Ilya

 

[Andrzejek]

>to avoid declaring a private or local memvar with the same name a public one, inadvertently.

That's where established code standards kick in.
Where I work, we name our variables showing the scope of the variable. So Public one for, let's say, LastName would be gstrLastName, where 'g' stands for 'global' (or 'public')


---- Andy

There is a great need for a sarcasm font.

 

[IlyaRabyy]

Right!
Wherever I worked, I always established the "good coding practices", one of them - to have scope prefix and data type prefix in memvar's name.
(This is why I hate implicit memvars' declaration of the yesteryears! My junior programmers at one company (mid-1990s) just declared lcMemVar = "Bla-bla-bla" - should be local char, right? But since they never declared it explicitly as such - it became PRIVATE, and then... all hell might break loose! When I told them I won't sign off or accept any code without explicit memvars' declaration - they started to declare them all PUBLIC... woe me!
But enough of that "going down memory lane"! T's XXI-st century now! ;-) )

Regards,

Ilya