473,836 Members | 1,520 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Tip for strongly typed references to sub/parent forms/

Yup, Steve's full of tips, but hey, it makes him feel important, right?

Ok, here goes. I've been trying to improve encapsulation by putting code
in the same object as the stuff it affects, so I rarely refer to a subform
ir parent form's controls or records from the other form. Instead, I call
a procedure in that form that does the job.

That's all fine and good, and nothing at all revolutionary, but it leaves
one with an annoying dilemma. Either, you refer to things like
Me.Parent.FooPr ocedure() and don't get auto-sense help or compile-time
checking, or you declare a variable of type Form_frmFooPare nt in each
function, set it = to Me.Parent, then use that. You can remove some of
that duplication by doing the assignment once to a private variable on the
form once during Form_Open, but then if you ever reset the code, the form
is broken until you close it and re-open it.

Here's the new habit I've devised.

In a subform that wants a strongly typed reference to its parent, add a
function as follows...

Private Function ParentInstance( ) As Form_frmFooPare nt
Set ParentInstance = Me.Parent
End Function

Now, when you want to refer to the parent, just say something like
ParentInstance( ).FooProcedure( ). Likewise, for each subform on a master
form, create a function in the master form's module like this...

Private Function FooChildInstanc e() As Form_frmFooChil d
Set FooChildInstanc e = Me!subFooChild. Form
End Function

Foo-ooo chi-iild - things are gooonna get easie-er.

Nov 12 '05 #1
25 6225
On Fri, 17 Oct 2003 07:05:28 GMT, Steve Jorgensen
<no****@nospam. nospam> wrote:

I have a habit of setting to nothing all variables I created with Set:
Set MyForm = Forms!SomeForm
....
Set MyForm = Nothing

Not sure if this is overkill, but using your syntax I couldn't do
that. It's similar to CurrentDb().Ope nRecordset often debated here
(and no definitive resolution afaik).

Have you seen any detrimental effects if you call your code a million
times?

-Tom.
Yup, Steve's full of tips, but hey, it makes him feel important, right?

Ok, here goes. I've been trying to improve encapsulation by putting code
in the same object as the stuff it affects, so I rarely refer to a subform
ir parent form's controls or records from the other form. Instead, I call
a procedure in that form that does the job.

That's all fine and good, and nothing at all revolutionary, but it leaves
one with an annoying dilemma. Either, you refer to things like
Me.Parent.FooP rocedure() and don't get auto-sense help or compile-time
checking, or you declare a variable of type Form_frmFooPare nt in each
function, set it = to Me.Parent, then use that. You can remove some of
that duplication by doing the assignment once to a private variable on the
form once during Form_Open, but then if you ever reset the code, the form
is broken until you close it and re-open it.

Here's the new habit I've devised.

In a subform that wants a strongly typed reference to its parent, add a
function as follows...

Private Function ParentInstance( ) As Form_frmFooPare nt
Set ParentInstance = Me.Parent
End Function

Now, when you want to refer to the parent, just say something like
ParentInstance ().FooProcedure (). Likewise, for each subform on a master
form, create a function in the master form's module like this...

Private Function FooChildInstanc e() As Form_frmFooChil d
Set FooChildInstanc e = Me!subFooChild. Form
End Function

Foo-ooo chi-iild - things are gooonna get easie-er.


Nov 12 '05 #2
Well, if that was a proble, then using Me.Parent withoout assigning it to a
variable and clearing it later should be a problem just as it is with the
use of CurrentDB. If it were a problem, I think we would all know about it
by now.

On Fri, 17 Oct 2003 07:24:05 -0700, Tom van Stiphout
<to*****@no.spa m.cox.net> wrote:
On Fri, 17 Oct 2003 07:05:28 GMT, Steve Jorgensen
<no****@nospam .nospam> wrote:

I have a habit of setting to nothing all variables I created with Set:
Set MyForm = Forms!SomeForm
...
Set MyForm = Nothing

Not sure if this is overkill, but using your syntax I couldn't do
that. It's similar to CurrentDb().Ope nRecordset often debated here
(and no definitive resolution afaik).

Have you seen any detrimental effects if you call your code a million
times?

-Tom.
Yup, Steve's full of tips, but hey, it makes him feel important, right?

Ok, here goes. I've been trying to improve encapsulation by putting code
in the same object as the stuff it affects, so I rarely refer to a subform
ir parent form's controls or records from the other form. Instead, I call
a procedure in that form that does the job.

That's all fine and good, and nothing at all revolutionary, but it leaves
one with an annoying dilemma. Either, you refer to things like
Me.Parent.Foo Procedure() and don't get auto-sense help or compile-time
checking, or you declare a variable of type Form_frmFooPare nt in each
function, set it = to Me.Parent, then use that. You can remove some of
that duplication by doing the assignment once to a private variable on the
form once during Form_Open, but then if you ever reset the code, the form
is broken until you close it and re-open it.

Here's the new habit I've devised.

In a subform that wants a strongly typed reference to its parent, add a
function as follows...

Private Function ParentInstance( ) As Form_frmFooPare nt
Set ParentInstance = Me.Parent
End Function

Now, when you want to refer to the parent, just say something like
ParentInstanc e().FooProcedur e(). Likewise, for each subform on a master
form, create a function in the master form's module like this...

Private Function FooChildInstanc e() As Form_frmFooChil d
Set FooChildInstanc e = Me!subFooChild. Form
End Function

Foo-ooo chi-iild - things are gooonna get easie-er.


Nov 12 '05 #3
no****@nospam.n ospam (Steve Jorgensen) wrote in
<95************ *************** *****@4ax.com>:
Well, if that was a proble, then using Me.Parent withoout
assigning it to a variable and clearing it later should be a
problem just as it is with the use of CurrentDB. If it were a
problem, I think we would all know about it by now.


Uh, Steve? Remember the bookmark bug? It wasn't found until Access
had been in use for over half a decade.

I think the solution here is something similar to MichKa's wrapper
for a global db variable to refer to the currently opened MDB. You
create a function that returns the reference, but make the function
self-initializing.

To me, changing your function to:

Module-level variable:

Private frmMyParent As Form

Private Function ParentInstance( ) As Form_frmFooPare nt
If frmMyParent Is Nothing Then Set frmMyParent = Me.Parent
ParentInstance = frmMyParent
End Function

This would get rid of the problem Tom has with it, as well as
making it more efficient. Then I'd put a Set frmMyParent = Nothing
in the UnLoad event of the child form, though it should technically
not be needed (but then, we don't depend on VBA to properly honor
object variable scope in other places, so why depend on it here?).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #4
On Oct 17 2003, 05:12 pm, dX********@bway .net.invalid (David W. Fenton)
wrote in news:94******** *************** ****@24.168.128 .90:
I think the solution here is something similar to MichKa's wrapper
for a global db variable to refer to the currently opened MDB. You
create a function that returns the reference, but make the function
self-initializing.

To me, changing your function to:

Module-level variable:

Private frmMyParent As Form

Private Function ParentInstance( ) As Form_frmFooPare nt
If frmMyParent Is Nothing Then Set frmMyParent = Me.Parent
ParentInstance = frmMyParent
End Function

This would get rid of the problem Tom has with it, as well as
making it more efficient. Then I'd put a Set frmMyParent = Nothing
in the UnLoad event of the child form


Even better, instead of a function, make it a Property Get/Property Set
pair, so that you can use the same name when referring to the instance and
setting the private variable to Nothing.

--
(remove a 9 to reply by email)
Nov 12 '05 #5
On Fri, 17 Oct 2003 21:12:46 GMT, dX********@bway .net.invalid (David W.
Fenton) wrote:
no****@nospam. nospam (Steve Jorgensen) wrote in
<95*********** *************** ******@4ax.com> :
Well, if that was a proble, then using Me.Parent withoout
assigning it to a variable and clearing it later should be a
problem just as it is with the use of CurrentDB. If it were a
problem, I think we would all know about it by now.
Uh, Steve? Remember the bookmark bug? It wasn't found until Access
had been in use for over half a decade.


Yup, but if this one is a bug, we've all been drinking from the poisoned
well for an awfully long time. Adding a function call in between the
..Parent reference and its use as a temporary immediate variable, I just
don't see how it could have any affect on the issue if there was one.
I think the solution here is something similar to MichKa's wrapper
for a global db variable to refer to the currently opened MDB. You
create a function that returns the reference, but make the function
self-initializing.

To me, changing your function to:

Module-level variable:

Private frmMyParent As Form

Private Function ParentInstance( ) As Form_frmFooPare nt
If frmMyParent Is Nothing Then Set frmMyParent = Me.Parent
ParentInstance = frmMyParent
End Function
I thought of that, and I do this kind of optimization all the time when I
have a need to, though when I do it, I use a static variable inside the
function instead of a private variable in the module. If the idea is to
provide a safe way of accessing the reference that works even if the code
gets reset, why invite trouble by making it accessible another way? Here's
what my version would look like...

Private Function ParentInstance( ) As Form_frmFooPare nt
Static sfrmParent As Form
If sfrmParent Is Nothing Then Set sfrmParent = Me.Parent
ParentInstance = sfrmParent
End Function

I don't do that for this function, though because I decided that to do so
was not so much anal retentive as obsessive compulsive (not that I haven't
been rightly accused of this attribute myself from time to time).
This would get rid of the problem Tom has with it, as well as
making it more efficient. Then I'd put a Set frmMyParent = Nothing
in the UnLoad event of the child form, though it should technically
not be needed (but then, we don't depend on VBA to properly honor
object variable scope in other places, so why depend on it here?).


More efficient, yes, but even without the optimization, I estimate that it
should still be greatly faster than some -really- slow operations such as
strFoo = "a". Personally, I choose not to bother with the optimization.
Nov 12 '05 #6
On 18 Oct 2003 00:05:21 GMT, Dimitri Furman <df*****@cloud9 9.net> wrote:
On Oct 17 2003, 05:12 pm, dX********@bway .net.invalid (David W. Fenton)
wrote in news:94******** *************** ****@24.168.128 .90:
I think the solution here is something similar to MichKa's wrapper
for a global db variable to refer to the currently opened MDB. You
create a function that returns the reference, but make the function
self-initializing.

To me, changing your function to:

Module-level variable:

Private frmMyParent As Form

Private Function ParentInstance( ) As Form_frmFooPare nt
If frmMyParent Is Nothing Then Set frmMyParent = Me.Parent
ParentInstance = frmMyParent
End Function

This would get rid of the problem Tom has with it, as well as
making it more efficient. Then I'd put a Set frmMyParent = Nothing
in the UnLoad event of the child form


Even better, instead of a function, make it a Property Get/Property Set
pair, so that you can use the same name when referring to the instance and
setting the private variable to Nothing.


I hate to be argumentative, but this takes a 3-line solution that's
extremely simple to type and maintain, and turns it into at least 8 lines
of code. Furthermore, you can't use the static variable trick for
encapsulation because Property Set and Property Get are separate functions
that can't share a static variable.
Nov 12 '05 #7
no****@nospam.n ospam (Steve Jorgensen) wrote in
<27************ *************** *****@4ax.com>:
On Fri, 17 Oct 2003 21:12:46 GMT, dX********@bway .net.invalid
(David W. Fenton) wrote:
no****@nospam .nospam (Steve Jorgensen) wrote in
<95********** *************** *******@4ax.com >:
Well, if that was a proble, then using Me.Parent withoout
assigning it to a variable and clearing it later should be a
problem just as it is with the use of CurrentDB. If it were a
problem, I think we would all know about it by now.
Uh, Steve? Remember the bookmark bug? It wasn't found until
Access had been in use for over half a decade.


Yup, but if this one is a bug, we've all been drinking from the
poisoned well for an awfully long time. . . .


All I'm saying is that just because something has been used for a
long time without any apparent problems does not mean that it
wouldn't be a problem in the future. That was what you said, and I
was just pointing out an example where it took 5 years to discover
a really significant problem with something that had been widely
used and no one had noticed the problem.
. . . Adding a function call in
between the .Parent reference and its use as a temporary immediate
variable, I just don't see how it could have any affect on the
issue if there was one.
I have *no* idea what you're talking about here.
I think the solution here is something similar to MichKa's
wrapper for a global db variable to refer to the currently opened
MDB. You create a function that returns the reference, but make
the function self-initializing.

To me, changing your function to:

Module-level variable:

Private frmMyParent As Form

Private Function ParentInstance( ) As Form_frmFooPare nt
If frmMyParent Is Nothing Then Set frmMyParent = Me.Parent
ParentInstance = frmMyParent
End Function


I thought of that, and I do this kind of optimization all the time
when I have a need to, though when I do it, I use a static
variable inside the function instead of a private variable in the
module. . . .


I've never used static variables because they don't fit with the
model in my head of how scope should work. I know they *do* work,
but it's one of those things that bothers me, so I just don't use
them.
. . . If the idea is to provide a safe way of accessing the
reference that works even if the code gets reset, why invite
trouble by making it accessible another way? Here's what my
version would look like...

Private Function ParentInstance( ) As Form_frmFooPare nt
Static sfrmParent As Form
If sfrmParent Is Nothing Then Set sfrmParent = Me.Parent
ParentInstance = sfrmParent
End Function
That makes perfect sense to me, yes.
I don't do that for this function, though because I decided that
to do so was not so much anal retentive as obsessive compulsive
(not that I haven't been rightly accused of this attribute myself
from time to time).


You don't think the amount of time it takes to initialize the form
variable is not significant? Well, maybe it's not, but why set
something that's already been initialized? I am always bothered by
such things -- I believe you should only do it when you need to,
unless figuring out whether or not you need to takes just as much
time as doing it.

Or, in this case, if there's a potential memory leak in setting the
object variable again without having set it to Nothing.

I doubt there's a problem there, but I don't know for certain.
This would get rid of the problem Tom has with it, as well as
making it more efficient. Then I'd put a Set frmMyParent =
Nothing in the UnLoad event of the child form, though it should
technically not be needed (but then, we don't depend on VBA to
properly honor object variable scope in other places, so why
depend on it here?).


More efficient, yes, but even without the optimization, I estimate
that it should still be greatly faster than some -really- slow
operations such as strFoo = "a". Personally, I choose not to
bother with the optimization.


This is a case where we'll have to agree to disagree.

To me, your code looks sloppy, because it doesn't consider the
context in which it's running. I believe that you should initialize
such variables once, rather than each time you call them. Your
function repeatedly does unnecessary work, and my version (or your
static variable variation) are much more efficient and just as
reliable.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #8
On Sat, 18 Oct 2003 21:06:05 GMT, dX********@bway .net.invalid (David W.
Fenton) wrote:
no****@nospam. nospam (Steve Jorgensen) wrote in
<27*********** *************** ******@4ax.com> :
On Fri, 17 Oct 2003 21:12:46 GMT, dX********@bway .net.invalid
(David W. Fenton) wrote:
no****@nospa m.nospam (Steve Jorgensen) wrote in
<95********* *************** ********@4ax.co m>:

Well, if that was a proble, then using Me.Parent withoout
assigning it to a variable and clearing it later should be a
problem just as it is with the use of CurrentDB. If it were a
problem, I think we would all know about it by now.

Uh, Steve? Remember the bookmark bug? It wasn't found until
Access had been in use for over half a decade.
Yup, but if this one is a bug, we've all been drinking from the
poisoned well for an awfully long time. . . .


All I'm saying is that just because something has been used for a
long time without any apparent problems does not mean that it
wouldn't be a problem in the future. That was what you said, and I
was just pointing out an example where it took 5 years to discover
a really significant problem with something that had been widely
used and no one had noticed the problem.


OK, sure, but it appears to me that if there's a problem with calling a
function that indirectly resolves and returns a reference to Me.Parent,
that has precisely the same reliability issues, no more, and no less, than
simply referring to M.Parent in the calling code. A hidden problem?
Hypothetically, but I never was worried about it before, so I wasn't
planning to start worrying about it because I'm now inserting a function
call between part A and part B of the expression.
. . . Adding a function call in
between the .Parent reference and its use as a temporary immediate
variable, I just don't see how it could have any affect on the
issue if there was one.


I have *no* idea what you're talking about here.


OK, when I refer to Me.Parent, that's a property reference that gives me
back an object reference to the parent control. In my code, if I make a
reference to Me.Parent!txtVa lue, I expect that, behind the scenes, VB is
creating a temporary reference to the parent form, then creating a
temporary reference to its default collection which is Controls (not
precisely, but close enough for this discussion), then looks up the control
with the name , "txtValue" in the colleciton, then finally looks up the
default value property (Value) and returns a variant from that. Finally,
all these temporary references fall out of scope.

Inserting a function call in the mix where the function call gets the
Me.Parent reference, and returns it to the calling function where it
remains temporarily until the rest of the chain is resolves makes very
little difference to the sequence of events, and I don't see how it could
insert any new issues, though it's true it won't solve any issues if they
already existed.
I think the solution here is something similar to MichKa's
wrapper for a global db variable to refer to the currently opened
MDB. You create a function that returns the reference, but make
the function self-initializing.

To me, changing your function to:

Module-level variable:

Private frmMyParent As Form

Private Function ParentInstance( ) As Form_frmFooPare nt
If frmMyParent Is Nothing Then Set frmMyParent = Me.Parent
ParentInstance = frmMyParent
End Function


I thought of that, and I do this kind of optimization all the time
when I have a need to, though when I do it, I use a static
variable inside the function instead of a private variable in the
module. . . .


I've never used static variables because they don't fit with the
model in my head of how scope should work. I know they *do* work,
but it's one of those things that bothers me, so I just don't use
them.


I use that same reasoning often. In this case, though, I've used static
variables for encapsulation enough now to trust the technique.
. . . If the idea is to provide a safe way of accessing the
reference that works even if the code gets reset, why invite
trouble by making it accessible another way? Here's what my
version would look like...

Private Function ParentInstance( ) As Form_frmFooPare nt
Static sfrmParent As Form
If sfrmParent Is Nothing Then Set sfrmParent = Me.Parent
ParentInstance = sfrmParent
End Function


That makes perfect sense to me, yes.
I don't do that for this function, though because I decided that
to do so was not so much anal retentive as obsessive compulsive
(not that I haven't been rightly accused of this attribute myself
from time to time).


You don't think the amount of time it takes to initialize the form
variable is not significant? Well, maybe it's not, but why set
something that's already been initialized? I am always bothered by
such things -- I believe you should only do it when you need to,
unless figuring out whether or not you need to takes just as much
time as doing it.


It may in fact be significant overhead for certain values of significant.
By percentage, the private or static variable reference is sure to be
faster by a significant amount. Still, the cost of allocating space on the
heap for a string would be higher in my estimation, but we all willingly do
that repeatedly in many functions without worrying about the cost
until/unless we see a performance problem - then we optimize. So, I could
see doing making the change for optimizaiton reasons in a form or 2 where a
performance issue came up, but otherwise, simple is good.
Or, in this case, if there's a potential memory leak in setting the
object variable again without having set it to Nothing.
Again, it is possible such an issue exists, but I'd decide to account for
that at the same time I decide I should never refer to Me.Parent without
assigning it to a variable, then setting it to Nothing when I was done with
it. If I didn't think I needed that before, then I don't think I need it
now. Of course, once the function is there and used, it's a convenient
place to put the fix later as you describe if an issue did prove to exist,
particularly in the case of subform references where search/replace can't
easily find all cases.
I doubt there's a problem there, but I don't know for certain.
This would get rid of the problem Tom has with it, as well as
making it more efficient. Then I'd put a Set frmMyParent =
Nothing in the UnLoad event of the child form, though it should
technicall y not be needed (but then, we don't depend on VBA to
properly honor object variable scope in other places, so why
depend on it here?).


More efficient, yes, but even without the optimization, I estimate
that it should still be greatly faster than some -really- slow
operations such as strFoo = "a". Personally, I choose not to
bother with the optimization.


This is a case where we'll have to agree to disagree.

To me, your code looks sloppy, because it doesn't consider the
context in which it's running. I believe that you should initialize
such variables once, rather than each time you call them. Your
function repeatedly does unnecessary work, and my version (or your
static variable variation) are much more efficient and just as
reliable.


I'm deciding that sloppy is sometimes OK, so long as it is consciously
chosen and considered, not simply due to thoughtlessness or ignorance. In
this case, I'm fine with choosing sloppy for the benefit of simplicity.

Here's another consideration. In the case of subform references from the
parent, it is actually possible that the subform reference could refer to
different subform objects at different times. If you keep a reference to
the subform so long as it's not Nothing, and the subform is changed, you
now have a non-Nothing reference to a closed form (the object still exists
because a reference remains even though the form is now closed).

So, if one was really committed to keeping a cached reference to the
subform, and assuming all errors not specifically handled in the function
should be raised to the calling code, I suppose one could write code like
this...

Private Function FooChildInstanc e() As Form_frmFooChil d
Static sfrmFooChild As Form_frmFooChil d
Dim blnDummy As Boolean
Proc_Start:
If sfrmFooChild Is Nothing Then
Set sfrmFooChild = Me!subFooChild. Form
Else
On Error Goto Proc_Err
blnDummy = Form.Modal
End If
Fn_Return:
Set FooChildInstanc e = sfrmFooChild
Proc_Err:
If Err.Number = constAccErrObje ctClosedOrNotEx ist Then ' = 2467
Set sfrmFooChild = Nothing
Resume Proc_Start
Else
Err.Raise Err.Number, , Err.Description
End If
End Function

So, I'm going to paste -this- all over my form modules? And we've lost
some of the performance gain we had. If I did decide this approach was
worth it (and I won't), then I would probably want to refactor most of this
into another class that I can set up with a subform control reference, then
ask it at any time for the Form reference, and have it do the above
gyrations. I could go on about what this could lead to - or I can keep
doing...

Private Function FooChildInstanc e() As Form_frmFooChil d
Set FooChildInstanc e = Me!subFooChild. Form
End Function

Granted, this line of reasoning does not apply to the Parent form case,
since the parent form reference can never change during the lifespan of the
subform.
Nov 12 '05 #9
no****@nospam.n ospam (Steve Jorgensen) wrote in
<4a************ *************** *****@4ax.com>:
Here's another consideration. In the case of subform references
from the parent, it is actually possible that the subform
reference could refer to different subform objects at different
times. If you keep a reference to the subform so long as it's not
Nothing, and the subform is changed, you now have a non-Nothing
reference to a closed form (the object still exists because a
reference remains even though the form is now closed).


I thought the code was running from the child form and was a public
function of the child form?

Therefore, as long as you have the same function in all the child
forms, it really doesn't matter.

Didn't you start this thread out by talking about putting all the
code close to where it operates? If so, why are you now talking
about a problem that exists only if you're breaking that principle?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
6093
by: Job Lot | last post by:
I am confused how strongly typed dataset is different from un-typed dataset. Is there any good link explaining pros and cons of both? Which one should be used preferably?
0
1855
by: MT | last post by:
I have an xsd file that I use to create a strongly typed dataset in my project. In the past, I have used the ReadXml method to load xml files into the generated class and read data in using this class. These files have now become big (order of 100MB) and this completely kills the readxml performance. I have read multiple posts that tell you not to use datasets for large files. I even tried calling BeginLoadTables before starting the...
2
2383
by: Mark | last post by:
Just wanted to confirm that my understanding of a strongly typed language is correct: 1. .NET is a strongly typed language because each variable / field must be declared a specific type (String, Int, Float, etc...) 2. VB 6 and VBScript were not strongly typed because both allowed you to ... dim blah .... which creates a variant.
7
7043
by: Jeff | last post by:
I want to remote several strongly typed datasets and I don't want to distribute the assemblies. I wish to create interface assemblies for these datasets but I don't know where to start. I've tried to use soapsuds, but this did not work correctly. I tried to use NMatrix XofG, but this seems very complicated. All I need is something that will convert a class file into an interface. Is there anything already built that will do this? ...
0
1026
by: jdipalmajr | last post by:
I noticed that I was getting performance issues when I referenced a strongly typed dataset using untyped references. When I changed my code to only use strongly typed references the performance was snappy. Why might this be the case? Seems like it should work either way. I am also using this dataset in a datagrid reference. Could the databinding be involved somehow?
20
5990
by: Dennis | last post by:
I use the following code for a strongly typed arraylist and it works great. However, I was wondering if this is the proper way to do it. I realize that if I want to implement sorting of the arraylist then I have to handle this with a sort method that uses comparer. I can reference the properties of the Arraylist directly such as dim mylist as new FrameList mylist.Add(new FrameStructure) mylist(0).first = "blabla..." mylist(0).second...
1
3573
by: Code Monkey | last post by:
Silly question maybe, but I've been doing the following for far too long now: public static DataTable myDataTable() { string sql = @"SELECT column1, column2, column3, column4 FROM myTable"; using (SqlConnection conn = new SqlConnection(websqlconn)) { SqlCommand cmd = new SqlCommand(sql, conn);
2
1701
by: =?Utf-8?B?UGV0ZXI=?= | last post by:
When I'm debugging a Windows Forms Application in VS2005 IDE, how can I check whether a dataset is strongly typed or not in Watch window? Are there some properties or methods only exist for strongly typed dataset?
4
3114
by: Rachana | last post by:
Hi, I have understood Data Sets but what is meant by typed/untyped/ strongly typed datasets. Can any one explain me or suggest any site/ article, to get these concepts (and their comparisions) cleared? Thanks, Rachana
0
9825
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
10854
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10558
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
9387
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7794
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5829
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4459
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4022
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3116
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.