Detecting Design Time vs Run Time Property Set action

[Mike]

I might be doing this all wrong, but logically, this is all I can
figure out what to do:

I have this custom component property:

Public Shadows Property Visible() As Boolean
Get
return TrayIcon.Visible
End Get
Set(ByVal value As Boolean)
TrayIcon.Visible = value
End Set
End Property

which expose/shadows the Visible property of a NotifyIcon dropped in
the custom component.

What I need is to determine id when you are in the DESIGN-TIME editor
or RUN-TIME so I can control when the above property is set or not set.

Whether the above is wrong way or not, in general, is it possible to
detect when you are in design time vs run time?

thanks

--

 

[Family Tree Mike]

I might be doing this all wrong, but logically, this is all I can figure
out what to do:

I have this custom component property:

Public Shadows Property Visible() As Boolean
Get
return TrayIcon.Visible
End Get
Set(ByVal value As Boolean)
TrayIcon.Visible = value
End Set
End Property

which expose/shadows the Visible property of a NotifyIcon dropped in the
custom component.

What I need is to determine id when you are in the DESIGN-TIME editor or
RUN-TIME so I can control when the above property is set or not set.

Whether the above is wrong way or not, in general, is it possible to
detect when you are in design time vs run time?

thanks

--

The property has the rather difficult to believe name of DesignMode

http://msdn.microsoft.com/en-us/library/system.componentmodel.component.designmode.aspx

 

[Family Tree Mike]

I might be doing this all wrong, but logically, this is all I can figure
out what to do:

I have this custom component property:

Public Shadows Property Visible() As Boolean
Get
return TrayIcon.Visible
End Get
Set(ByVal value As Boolean)
TrayIcon.Visible = value
End Set
End Property

which expose/shadows the Visible property of a NotifyIcon dropped in the
custom component.

What I need is to determine id when you are in the DESIGN-TIME editor or
RUN-TIME so I can control when the above property is set or not set.

Whether the above is wrong way or not, in general, is it possible to
detect when you are in design time vs run time?

thanks

--

The property has the rather difficult to believe name of DesignMode

http://msdn.microsoft.com/en-us/library/system.componentmodel.component.designmode.aspx

 

[Mike]

Wonderful! Thanks!

Its behaving correctly now:

Private _visible As Boolean = True
<Description("Turn on/off visibility of tray icon"), _
Category("Appearance"), _
DefaultValue(False)> _
Public Shadows Property Visible() As Boolean
Get
If Not Me.DesignMode Then _visible = TrayIcon.Visible
Return _visible
End Get
Set(ByVal value As Boolean)
_visible = value
If Not Me.DesignMode Then TrayIcon.Visible = _visible
End Set
End Property

It was really more of a annoying nit of seeing design-time icon in the
system tray during design when the custom component Visible property
was set true or defaulted true. Runtime no problem.

But that also tells me that I have two instances (verified via debug
trace), so I think I need to approach this by dynamically creating the
NotifyIcon in the custom component or better understand this auto
generated ME, MyBASE, MyClass globals and the designer partial
classes to grasp how the instances are created which is something that
I am across a lot.

In other words, I am having mental issues with these like this:

dim X as TYPE 'static instance in local scope
vs
dim X as NEW TYPE 'dynamic instance in global heap

I wired to program with the idea the constructor and destructor is
always called in both cases. With VB.NET, New() AFAIS, it is only
called when the object is created dynamically. Its a different way of
thinking in OOPs.

I hope anders and the VB.NET design time as they move to make VB.NET,
C#, C++/CLR singular as a fundamental considerations, including mixing
languages. That was what Anders spoke about as a goal for the MS .NET
languages.

Maybe what they can consider to keep it "VB" like is add support for
this well known concept is something like:

Public Class FOOBAR
<constructor(true)> sub new()
end sub
<destructor(true)> sub finalize()
end sub
End Class

with new attributes:

constructor(optional persistent as boolean = true)
destructor(optional persistent as boolean = true)

when persistent is true, it means that static instances will always
call the constructor and destructor when the local scope is lost.

Whatever.

--

 

[Mike]

Wonderful! Thanks!

Its behaving correctly now:

Private _visible As Boolean = True
<Description("Turn on/off visibility of tray icon"), _
Category("Appearance"), _
DefaultValue(False)> _
Public Shadows Property Visible() As Boolean
Get
If Not Me.DesignMode Then _visible = TrayIcon.Visible
Return _visible
End Get
Set(ByVal value As Boolean)
_visible = value
If Not Me.DesignMode Then TrayIcon.Visible = _visible
End Set
End Property

It was really more of a annoying nit of seeing design-time icon in the
system tray during design when the custom component Visible property
was set true or defaulted true. Runtime no problem.

But that also tells me that I have two instances (verified via debug
trace), so I think I need to approach this by dynamically creating the
NotifyIcon in the custom component or better understand this auto
generated ME, MyBASE, MyClass globals and the designer partial
classes to grasp how the instances are created which is something that
I am across a lot.

In other words, I am having mental issues with these like this:

dim X as TYPE 'static instance in local scope
vs
dim X as NEW TYPE 'dynamic instance in global heap

I wired to program with the idea the constructor and destructor is
always called in both cases. With VB.NET, New() AFAIS, it is only
called when the object is created dynamically. Its a different way of
thinking in OOPs.

I hope anders and the VB.NET design time as they move to make VB.NET,
C#, C++/CLR singular as a fundamental considerations, including mixing
languages. That was what Anders spoke about as a goal for the MS .NET
languages.

Maybe what they can consider to keep it "VB" like is add support for
this well known concept is something like:

Public Class FOOBAR
<constructor(true)> sub new()
end sub
<destructor(true)> sub finalize()
end sub
End Class

with new attributes:

constructor(optional persistent as boolean = true)
destructor(optional persistent as boolean = true)

when persistent is true, it means that static instances will always
call the constructor and destructor when the local scope is lost.

Whatever.

--

 

[Cor Ligthert[MVP]]

Mike

You use the sentence Run Time, are you aware that everything you do is in
Design Time as long as you not use reflection (which only result will be
that your application becomes slower and has more changes to break
unexpected)

Things done in the designer are simply set as program code in your program.

Cor

 

[Cor Ligthert[MVP]]

Mike

You use the sentence Run Time, are you aware that everything you do is in
Design Time as long as you not use reflection (which only result will be
that your application becomes slower and has more changes to break
unexpected)

Things done in the designer are simply set as program code in your program.

Cor

 

[Jack Jackson]

Be aware that DesignMode may not always do what you want with nested
controls.

Say you have two UserControls, UA and UB. UA contains an instance of
UB. When you drop UA in a form, UA's DesignMode property will be
True, but the DesignMode property of UB will be False.

 

[Jack Jackson]

Be aware that DesignMode may not always do what you want with nested
controls.

Say you have two UserControls, UA and UB. UA contains an instance of
UB. When you drop UA in a form, UA's DesignMode property will be
True, but the DesignMode property of UB will be False.

 

[Mike]

By Run Time, it generally means outside the IDE, running the compiled
code which I "presume" all the designer, debugging attributes,
designer hints are removed.

Are you referring to RTI (Run Time Information) that is embedded in
the compiled code? Yes, I am familiar with RTI in oops languages for
useful for concepts such as serialization, collections, lookups and
comparison of named objects.

--

 

[Mike]

By Run Time, it generally means outside the IDE, running the compiled
code which I "presume" all the designer, debugging attributes,
designer hints are removed.

Are you referring to RTI (Run Time Information) that is embedded in
the compiled code? Yes, I am familiar with RTI in oops languages for
useful for concepts such as serialization, collections, lookups and
comparison of named objects.

--

 

[Mike]

Interesting. I'll keep that in mind. Thanks

--

Be aware that DesignMode may not always do what you want with nested
controls.

Say you have two UserControls, UA and UB. UA contains an instance of
UB. When you drop UA in a form, UA's DesignMode property will be
True, but the DesignMode property of UB will be False.

 

[Mike]

Interesting. I'll keep that in mind. Thanks

--

Be aware that DesignMode may not always do what you want with nested
controls.

Say you have two UserControls, UA and UB. UA contains an instance of
UB. When you drop UA in a form, UA's DesignMode property will be
True, but the DesignMode property of UB will be False.

 

[Cor Ligthert[MVP]]

No it is not,

Setting a Design property is something that happens at runtime.

Cor

 

[Cor Ligthert[MVP]]

No it is not,

Setting a Design property is something that happens at runtime.

Cor

 

[Mike]

But it set to false. Right?

What you are saying, I think, is that if you are outside the IDE, you
can if you wanted to, set it to true if your application was going to
do IDE-like design time editing using the RTI.

--

 

[Mike]

But it set to false. Right?

What you are saying, I think, is that if you are outside the IDE, you
can if you wanted to, set it to true if your application was going to
do IDE-like design time editing using the RTI.

--