472,794 Members | 2,168 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,794 software developers and data experts.

*auto virtual* feature

Wouldn't it be nice if we could do something like this:

class Funky{

public: auto virtual void doStuff(){
// dostuff
}

};

class MoreFunky: public Funky{

public: void doStuff(){
// do more stuff
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
// do advanced stuff
}

};

main(){

AdvancedFunky f;
f.doStuff();
}
Now, call to *auto virtual* member doStuff() should follow the same
logic as a constructor call in inheritance chain, i. e. when calling
f.doStuff() we got all doStuff() functions executed from bottom up:

Funky::doStuff()
MoreFunky::doStuff()
AdvancedFunky::doStuff()

I think this feature could save us a lot of headache.
Jul 22 '05 #1
18 2118
"nenad" <ne***@medix.com.hr> wrote in message
news:41**************************@posting.google.c om...
Wouldn't it be nice if we could do something like this:

class Funky{

public: auto virtual void doStuff(){
// dostuff
}

};

class MoreFunky: public Funky{

public: void doStuff(){
// do more stuff
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
// do advanced stuff
}

};

main(){

AdvancedFunky f;
f.doStuff();
}
Now, call to *auto virtual* member doStuff() should follow the same
logic as a constructor call in inheritance chain, i. e. when calling
f.doStuff() we got all doStuff() functions executed from bottom up:

Funky::doStuff()
MoreFunky::doStuff()
AdvancedFunky::doStuff()

I think this feature could save us a lot of headache.


It is unnecessary and would not likely affect the sales of paracetamol
significantly. Furthermore, it is not for the class at the top to pronounce
from on high how another class's virtual functions should operate.

DW

Jul 22 '05 #2
nenad wrote:
Wouldn't it be nice if we could do something like this:

class Funky{

public: auto virtual void doStuff(){
// dostuff
}

};

class MoreFunky: public Funky{

public: void doStuff(){
// do more stuff
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
// do advanced stuff
}

};

main(){

AdvancedFunky f;
f.doStuff();
}
Now, call to *auto virtual* member doStuff() should follow the same
logic as a constructor call in inheritance chain, i. e. when calling
f.doStuff() we got all doStuff() functions executed from bottom up:

Funky::doStuff()
MoreFunky::doStuff()
AdvancedFunky::doStuff()

I think this feature could save us a lot of headache.


What is the problem with writing the following?

class Funky{
public: virtual void doStuff(){
std::cout << "Funky::doStuff()\n";
}
};

class MoreFunky: public Funky{
public: void doStuff(){
Funky::doStuff();
std::cout << "MoreFunky::doStuff()\n";
}

};

class AdvancedFunky: public MoreFunky{
public: void doStuff(){
MoreFunky::doStuff();
std::cout << "AdvancedFunky::doStuff()\n";
}
};

Michael Mellor
Jul 22 '05 #3
> I think this feature could save us a lot of headache.

Would this really save that much? I don't see what it saves other than
writing one line in each function, i.e. :

class Funky{

public : doStuff() {
// dostuff
}

} ;

class MoreFunky: public Funky{

public: void doStuff(){
Funky::dostuff() ;
// do more stuff
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
MoreFunky::dostuff() ;
// do advanced stuff
}

} ;

This achieves the behavior you want quite easily without a language
extension and without virtual functions. Moreover, it allows you to
control the order of the functions calls. Suppose you want to have
them executed in order :

AdvancedFunky::doStuff()
MoreFunky::doStuff()
Funky::doStuff()

then just change the code to :

class MoreFunky: public Funky{

public: void doStuff(){
// do more stuff
Funky::dostuff() ;
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
// do advanced stuff
MoreFunky::dostuff() ;
}

} ;

Or any other mix you prefer. How would this be accomplished with "auto
virtual"? Would be need another keyword such as "reverse auto virtual"
or "retro virtual"?
Jul 22 '05 #4
du****@mit.edu (Keith H Duggar) wrote in message news:<b4*************************@posting.google.c om>...
I think this feature could save us a lot of headache.
Would this really save that much? I don't see what it saves other than
writing one line in each function, i.e. :

class Funky{

public : doStuff() {
// dostuff
}

} ;

class MoreFunky: public Funky{

public: void doStuff(){
Funky::dostuff() ;
// do more stuff
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
MoreFunky::dostuff() ;
// do advanced stuff
}

} ;

This achieves the behavior you want quite easily without a language
extension and without virtual functions. Moreover, it allows you to
control the order of the functions calls. Suppose you want to have
them executed in order :

AdvancedFunky::doStuff()
MoreFunky::doStuff()
Funky::doStuff()

then just change the code to :

class MoreFunky: public Funky{

public: void doStuff(){
// do more stuff
Funky::dostuff() ;
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
// do advanced stuff
MoreFunky::dostuff() ;
}

} ;

Or any other mix you prefer. How would this be accomplished with "auto
virtual"? Would be need another keyword such as "reverse auto virtual"
or "retro virtual"?

:) Well, maybe the choice of "auto" is a bit stupid ( I just took
first kw that came to my mind). More appropriate would be
"constructorlike" :)

Would this really save that much? I don't see what it saves other than
writing one line in each function, i.e. :

class Funky{

public : doStuff() {
// dostuff
}

} ;

class MoreFunky: public Funky{

public: void doStuff(){
Funky::dostuff() ;
// do more stuff
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
MoreFunky::dostuff() ;
// do advanced stuff
}

} ;

This achieves the behavior you want quite easily without a language
extension and without virtual functions.


Yes. It is nice in this trivial case. But I don't *want* this kind of
behavior. What I want is constructor-like behavior. Consider this:

class Funky{

public: void doStuff(){
// do stuff
}
};

class MoreFunky: virtual public Funky{

public: void doStuff(){
Funky::doStuff();
// do more stuff
}
};

class AdvancedFunky: virtual public Funky{

public: void doStuff(){
Funky::doStuff();
// do advanced stuff
}
};

class SuperFunky: public AdvancedFunky, public MoreFunky{

public: void doStuff(){
MoreFunky::doStuff();
AdvancedFunky::doStuff();
// do super stuff
}
};

Now it becomes messy because Funky::doStuff() is called twice. And it
gets worse as we multiple-inherit further - more and more
Funky::doStuff()'s are called.
I made a little mistake putting focus on *virtual member functions*.
The issue here is *multiple/virtual inheritance*.
When we multiple inherit, the virtual inheritance mechanism eliminates
duplicate calls to base class constructors. Why not allow this kind of
behavior to ordinary functions (of course if we want to)?
The constructor call logic is pretty straightforward - each
constructor participates in initialisation of it's own piece of final
object. And it happens automatically, the compiler takes care of this.
Is's not hard to imagine the member function could act the same way -
changing it's piece of object down the inheritance chain( skiping the
duplicate base-calls in case of virtual inheritance).
The best solution to this problem ( at least to my humble knowledge )
is something like this:

class Funky{

public: void doStuff(){
doMyStuff();
}
protected: void doMyStuff(){
// do stuff
}

};

class MoreFunky: virtual public Funky{

public: void doStuff(){
Funky::doMyStuff();
doMyStuff();
}
protected: void doMyStuff(){
// do more stuff
}
};

class AdvancedFunky: virtual public Funky{

public: void doStuff(){
Funky::doMyStuff();
doMyStuff();
}
protected: void doMyStuff(){
// do advanced stuff
}
};

class SuperFunky: public AdvancedFunky, public MoreFunky{

public: void doStuff(){
Funky::doMyStuff();
MoreFunky::doMyStuff();
AdvancedFunky::doMyStuff();
doMyStuff();
}
protected: void doMyStuff(){
// do super stuff
}
};

This is pretty ugly as we now have to manage parasite doStuff() member
which does nothing except bunch of calls to doMyStuff()'s. The list of
calls gets biger as we inherit more. Imagine what class would look
like if we'd have dozens of members like this. On top of that, we must
have knowlege of whole inheritance tree if we're up to deriving the
new class.
Instead, I would like to have:

class Funky{

public: constuctorlike void doStuff(){
// do stuff
}
};

class MoreFunky: virtual public Funky{

public: void doStuff(){
// do more stuff
};

class AdvancedFunky: virtual public Funky{

public: void doStuff(){
// do advanced stuff
}
};

class SuperFunky: public AdvancedFunky, public MoreFunky{

public: void doStuff(){
// do super stuff
}
};

The similarity with virtual member is that you define behavior of the
function in base class and it continues to behave that way in all
derived classes. That's what I meant by *auto virtual*. If that
function is at the same time virtual, one would declare it like:

auto virtual virtual void doStuff();

//or better:

constructorlike virtual void doStuff();

//or some fancy new keyword

:)
well, I'm probably talking total bs
Jul 22 '05 #5

"nenad" <ne***@medix.com.hr> wrote in message
news:41**************************@posting.google.c om...
Wouldn't it be nice if we could do something like this:

class Funky{

public: auto virtual void doStuff(){
// dostuff
}

};

class MoreFunky: public Funky{

public: void doStuff(){
// do more stuff
}

};

class AdvancedFunky: public MoreFunky{

public: void doStuff(){
// do advanced stuff
}

};

main(){

AdvancedFunky f;
f.doStuff();
}
Now, call to *auto virtual* member doStuff() should follow the same
logic as a constructor call in inheritance chain, i. e. when calling
f.doStuff() we got all doStuff() functions executed from bottom up:

Funky::doStuff()
MoreFunky::doStuff()
AdvancedFunky::doStuff()

I think this feature could save us a lot of headache.


How would you implement it?

Jonathan
Jul 22 '05 #6
Oh ok, now that you've mentioned virtual inheritance I think I
understand more clearly what you are looking for. I agree that the
working solution you came up with isn't ideal since it does require
knowledge of the entire inheritance tree and lots of function
tracking.

It is an interesting idea you have to give constructor like behavior
to regular functions. I'd love to hear more informed commentary on the
topic than I can offer. What do you think of this runtime solution? (
I've renamed things a bit for simplicity I hope you don't mind the
change. ) It does eliminate the need for knowing the entire
inheritance hierarchy but necessitates an extra state variable in each
instance as well as an auxiliary function. Clearly not as convenient
as support for "constructor like" behavior.

#include <iostream>

class Base {
bool __print ;
public :
Base ( ) { print ( ) ; }
void reset ( ) { __print = true ; }
void print ( ) {
if ( __print ) {
std::cout << "Base\n" ;
__print = false ;
}
}
} ;

class Derv1A : virtual public Base {
bool __print ;
public :
Derv1A ( ) { print ( ) ; }
void reset ( ) {
Base::reset () ;
__print = true ; }
void print ( ) {
if ( __print ) {
Base::print() ;
std::cout << "Derv1A\n" ;
__print = false ;
}
}
} ;

class Derv1B : virtual public Base {
bool __print ;
public :
Derv1B ( ) { print ( ) ; }
void reset ( ) {
Base::reset () ;
__print = true ; }
void print ( ) {
if ( __print ) {
Base::print() ;
std::cout << "Derv1B\n" ;
__print = false ;
}
}
} ;

class Derv2 : public Derv1A , public Derv1B {
bool __print ;
public :
Derv2 ( ) { print ( ) ; }
void reset ( ) {
Derv1A::reset () ;
Derv1B::reset () ;
__print = true ; }
void print ( ) {
if ( __print ) {
Derv1A::print() ;
Derv1B::print() ;
std::cout << "Derv2\n" ;
__print = false ;
}
}
} ;

int main ( int argc , char * argv[] ) {

std::cout << "constructor\n" ;
Derv2 derv2 ;
std::cout << "\nfunction\n" ;
derv2.reset() ;
derv2.print() ;

return 0 ;
}
Jul 22 '05 #7
>
How would you implement it?

Jonathan


On the compiler level of course.
I don't see a problem in implementing it.
Jul 22 '05 #8
> What do you think of this runtime solution? (
I've renamed things a bit for simplicity I hope you don't mind the
change. ) It does eliminate the need for knowing the entire
inheritance hierarchy but necessitates an extra state variable in each
instance as well as an auxiliary function. Clearly not as convenient
as support for "constructor like" behavior.


Yes, but now you have extra calls to Base::reset(). Ok, it's a
reasonable trade-off for not needing to know the whole hierarchy tree.
But this implementation still looks confusing and the whole thing
feels like doing some kind of a language hack. Having constructor-like
members in this case feels kinda right.
Take a look at the case I'm stuck with:

#include <list>

using std::list;

class Base {
int base_data;
list< Base* > children;
Base * parent;

public: virtual ~Base();
};

class Derv1A : virtual public Base {
int deriv1a_data;
};

class Derv1B : virtual public Base {
int deriv1b_data;
};

class Derv2 : public Derv1A , public Derv1B {
int deriv2_data;
};

It's a polymorphic tree structure. I'd really like to see the
implementation of virtual operator=(...) here. The one that duplicates
children objects and handles future derived classes well.
Jul 22 '05 #9
nenad wrote:
What do you think of this runtime solution? (
I've renamed things a bit for simplicity I hope you don't mind the
change. ) It does eliminate the need for knowing the entire
inheritance hierarchy but necessitates an extra state variable in
each instance as well as an auxiliary function. Clearly not as
convenient as support for "constructor like" behavior.
Yes, but now you have extra calls to Base::reset(). Ok, it's a
reasonable trade-off for not needing to know the whole hierarchy tree.
But this implementation still looks confusing and the whole thing
feels like doing some kind of a language hack. Having constructor-like
members in this case feels kinda right.


Usually, you should split your function up into a non-virtual part that
is done in the base class and a private virtual function in the derived
classes.
Take a look at the case I'm stuck with:

#include <list>

using std::list;

class Base {
int base_data;
list< Base* > children;
Base * parent;

public: virtual ~Base();
};

class Derv1A : virtual public Base {
int deriv1a_data;
};

class Derv1B : virtual public Base {
int deriv1b_data;
};

class Derv2 : public Derv1A , public Derv1B {
int deriv2_data;
};

It's a polymorphic tree structure. I'd really like to see the
implementation of virtual operator=(...) here.
A virtual operator= isn't very useful, since it would need to alter the
class of the object it's called for when used polymorphically. That,
however, isn't possible.
The one that duplicates children objects and handles future derived
classes well.


How would your suggestion help here?

Jul 22 '05 #10

"nenad" <ne***@medix.com.hr> wrote in message
news:41**************************@posting.google.c om...

How would you implement it?

Jonathan
On the compiler level of course.


Of course.
I don't see a problem in implementing it.


I asked how, not whether you see a problem. Would the compiler just
add code at the beginning of the function body statically invoking the
function for the immediate base class? How is this virtual?

Jonathan
Jul 22 '05 #11
nenad wrote:
What do you think of this runtime solution? (
I've renamed things a bit for simplicity I hope you don't mind the
change. ) It does eliminate the need for knowing the entire
inheritance hierarchy but necessitates an extra state variable in each
instance as well as an auxiliary function. Clearly not as convenient
as support for "constructor like" behavior.

Yes, but now you have extra calls to Base::reset(). Ok, it's a
reasonable trade-off for not needing to know the whole hierarchy tree.
But this implementation still looks confusing and the whole thing
feels like doing some kind of a language hack. Having constructor-like
members in this case feels kinda right.
Take a look at the case I'm stuck with:

#include <list>

using std::list;

class Base {
int base_data;
list< Base* > children;
Base * parent;

public: virtual ~Base();
};

class Derv1A : virtual public Base {
int deriv1a_data;
};

class Derv1B : virtual public Base {
int deriv1b_data;
};

class Derv2 : public Derv1A , public Derv1B {
int deriv2_data;
};

It's a polymorphic tree structure. I'd really like to see the
implementation of virtual operator=(...) here. The one that duplicates
children objects and handles future derived classes well.

How does a *virtual* operator= help here?
Yould could just
#include <list>

using std::list;

class Base {
int base_data;
list< Base* > children;
Base * parent;

public: virtual ~Base() { };
Base &operator=(Base &other) {
// Do deep copy
return *this;
}
};

class Derv1A : virtual public Base {
int deriv1a_data;
};

class Derv1B : virtual public Base {
int deriv1b_data;
};

class Derv2 : public Derv1A , public Derv1B {
int deriv2_data;
};

int main ( ) {
Derv2 a, b;
b = a;
}

and except that there is a possibility of the operator= being called
twice, or do some clever code to avoid the penalty of two deep copies
but I dont see how a virtual operator= helps in either case?

Michael Mellor
Jul 22 '05 #12
"Jonathan Turkanis" <te******@kangaroologic.com> wrote
I asked how, not whether you see a problem. Would the compiler just
add code at the beginning of the function body statically invoking the
function for the immediate base class? How is this virtual?


* statically invoking the function for the immediate base class *
could be done by typing it. Main problem is what to do in case of
virtual inheritance to avoid overlapping base-calls.

Ok I was sloppy with choice of *keyword(s)*. Virtual in *auto virtual*
is reffering to proper behavior in context of virtual inheritance.
Let's forget about *auto virtual* and call this behavior
*constructorlike* ( just for the sake of clarity ).

You would declare ordinary constructorlike member:

constructorlike void func();

When you call such a function compiler would statically generate
series of all base-calls ( bottom-up ) avoiding duplicate calls in
case of virtual inheritance. Note that this is useless if you don't
have virtual-inherited class hierarchy.

Or if the function is virtual:

constructorlike virtual void func();

Imlementation here depends on how virtual calls are done. For most
common case using vptr+vtable compiler would generate a loop that
walks up the vtable, calling available functions, finishing at table
pointed by vptr. So no extra hidden data per object is needed ( of
course, this is extremely simplified explanation ).
Anyway I wouldn't mind if some additional hidden data is involved - as
in the case of virtual calls - you somehow must pay for a fancy ride.
Jul 22 '05 #13
Michael Mellor wrote
and except that there is a possibility of the operator= being called
twice, or do some clever code to avoid the penalty of two deep copies


Yes, that exactly was reason for suggesting something like
*constructorlike* member function; to avoid multiple calls without
doing the clever code.

How would you implement operator= here:

#include <list>

using std::list;

class Base {
list< Base* > children;
Base * parent;
};

class Derv1A : virtual public Base {
char * needsToBeDuplicated1;
};

class Derv1B : virtual public Base {
char * needsToBeDuplicated2;
};

class Derv2 : public Derv1A , public Derv1B {
char * needsToBeDuplicated3;
};

You'd probably need come kind of virtual copy() function that is
called from Base::operator=(). But this is painful as every copy() in
derived class must implement whole copying code that is already
implemented in base classes. Or you can use scheme in which every
copy() does it's own copying and calls all immediate-base copy()'s,
propagating calls to the top hence doing multiple calls to same
base-members. The number of unnecessary calls could get quite big if
you have large inheritance tree.
If we'd have some kind of automatic constructor-like behavior attached
to copy() this would no lenger be a problem.
Jul 22 '05 #14
nenad wrote:
Michael Mellor wrote
and except that there is a possibility of the operator= being called
twice, or do some clever code to avoid the penalty of two deep copies

Yes, that exactly was reason for suggesting something like
*constructorlike* member function; to avoid multiple calls without
doing the clever code.

How would you implement operator= here:

#include <list>

using std::list;

class Base {
list< Base* > children;
Base * parent;
};

class Derv1A : virtual public Base {
char * needsToBeDuplicated1;
};

class Derv1B : virtual public Base {
char * needsToBeDuplicated2;
};

class Derv2 : public Derv1A , public Derv1B {
char * needsToBeDuplicated3;
};

You'd probably need come kind of virtual copy() function that is
called from Base::operator=(). But this is painful as every copy() in
derived class must implement whole copying code that is already
implemented in base classes. Or you can use scheme in which every
copy() does it's own copying and calls all immediate-base copy()'s,
propagating calls to the top hence doing multiple calls to same
base-members. The number of unnecessary calls could get quite big if
you have large inheritance tree.
If we'd have some kind of automatic constructor-like behavior attached
to copy() this would no lenger be a problem.


Will you be assigning to the base object? because this will have problems.

Base *p = new Derv2;
Base *a = new Derv1A;
.....
p->copy(*a);
This is legal so you will need to implement runtime checks that the rhs
of the assignment is the object you expect it to be.

Personally I prefer to only assign to the object as its actual type.
Then you will only need the an operator= for Base which can use a simple
copy-on-write system to avoid the double copy. The default operator=
will be fine for the other classes.

Michael Mellor
Jul 22 '05 #15
nenad wrote:
Michael Mellor wrote
and except that there is a possibility of the operator= being called
twice, or do some clever code to avoid the penalty of two deep copies


Yes, that exactly was reason for suggesting something like
*constructorlike* member function; to avoid multiple calls without
doing the clever code.

How would you implement operator= here:

#include <list>

using std::list;

class Base {
list< Base* > children;
Base * parent;
};

class Derv1A : virtual public Base {
char * needsToBeDuplicated1;
};

class Derv1B : virtual public Base {
char * needsToBeDuplicated2;
};

class Derv2 : public Derv1A , public Derv1B {
char * needsToBeDuplicated3;
};

You'd probably need come kind of virtual copy() function that is
called from Base::operator=().


That still won't work. operator= can't change the class of the object it
is called for. And your language extenstion won't change anything about
that fact.

Jul 22 '05 #16

"nenad" <ne***@medix.com.hr> wrote in message
news:41**************************@posting.google.c om...
"Jonathan Turkanis" <te******@kangaroologic.com> wrote

Imlementation here depends on how virtual calls are done. For most
common case using vptr+vtable compiler would generate a loop that
walks up the vtable, calling available functions, finishing at table
pointed by vptr. So no extra hidden data per object is needed ( of
course, this is extremely simplified explanation ).
Anyway I wouldn't mind if some additional hidden data is involved - as in the case of virtual calls - you somehow must pay for a fancy

ride.

I'm not convinced this is simple.In general, with virtual inheritance,
there can be more than one virtual table per class. Constructors
insert pointers to the correct vtables a construction. I think you
need more detail here.

Best Regards,

Jonathan
Jul 22 '05 #17
"Jonathan Turkanis" wrote

I'm not convinced this is simple.In general, with virtual inheritance,
there can be more than one virtual table per class. Constructors
insert pointers to the correct vtables a construction. I think you
need more detail here.


Well I newer said I had an ambition to implement it. I'm sure someone
smarter than me can do it properly.
Jul 22 '05 #18
nenad wrote:
"Jonathan Turkanis" wrote

I'm not convinced this is simple.In general, with virtual
inheritance, there can be more than one virtual table per class.
Constructors insert pointers to the correct vtables a construction. I
think you need more detail here.


Well I newer said I had an ambition to implement it. I'm sure someone
smarter than me can do it properly.


Adding a language feature always needs to consider two sides. The
programmer's side and the compiler writer's side.

Jul 22 '05 #19

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

Similar topics

7
by: Karsten Hochkirch | last post by:
Hi, I have just encountered a problem when calling a virtual member function in a constructor. Only the memberfunction of the parent class is called instead of the overloaded function. I...
26
by: pmizzi | last post by:
When i compile my program with the -ansi -Wall -pedantic flags, i get this warning: `class vechile' has virtual functions but non-virtual destructor, and the same with my sub-classes. But when i...
4
by: reb | last post by:
I more or less inherited some code that makes liberal use of STL, among other things. Up to now I've sort of considered templates a kind of black art, but I'm coming around to see how they can be...
32
by: Adrian Herscu | last post by:
Hi all, In which circumstances it is appropriate to declare methods as non-virtual? Thanx, Adrian.
14
by: JPRoot | last post by:
Hi I use the following syntax to have events inherited from base to child classes which works nicely (virtual and override keyword on events). But I am wondering if it is a "supported" way of using...
8
by: JPRoot | last post by:
Hi M. Jeffrey Tan, Just hopping you didn't forget me? :) Thanks JPRoot ----- \"Jeffrey Tan\" wrote: -----
9
by: junlia | last post by:
Does anyone how how can we disable the auto-postback feature in asp.net page? I have to use a server side control in the page, but the auto post back feature in it causes problems for me. Please...
1
by: glasssd | last post by:
Hi, I was hoping someone might have some ideas on how I can hack around a problem I'm having with the auto-complete feature of the ComboBox. I have a data entry application that uses a pair of...
1
DebadattaMishra
by: DebadattaMishra | last post by:
Introduction In case of rich applications, you must have observed that a text field behaves like a dynamic combo box. When the user enters some characters in the text field, a popup will come up...
0
by: erikbower65 | last post by:
Using CodiumAI's pr-agent is simple and powerful. Follow these steps: 1. Install CodiumAI CLI: Ensure Node.js is installed, then run 'npm install -g codiumai' in the terminal. 2. Connect to...
0
linyimin
by: linyimin | last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Sept 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM) The start time is equivalent to 19:00 (7PM) in Central...
0
by: Taofi | last post by:
I try to insert a new record but the error message says the number of query names and destination fields are not the same This are my field names ID, Budgeted, Actual, Status and Differences ...
14
DJRhino1175
by: DJRhino1175 | last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this - If...
0
by: Rina0 | last post by:
I am looking for a Python code to find the longest common subsequence of two strings. I found this blog post that describes the length of longest common subsequence problem and provides a solution in...
0
by: lllomh | last post by:
Define the method first this.state = { buttonBackgroundColor: 'green', isBlinking: false, // A new status is added to identify whether the button is blinking or not } autoStart=()=>{
0
by: lllomh | last post by:
How does React native implement an English player?
2
by: DJRhino | last post by:
Was curious if anyone else was having this same issue or not.... I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...

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.