|
Thanks for replying.
If I'm correct, I believe ALL objects of a certain type, share the same functions of that particular type, which means by qualifying the functions with its class name, I am specifying its type.
This does not hold true for the data portion of objects of the same type. To reference the data portion of an object, you must qualify it with that specific object.
In any case, even when I do the following, the functions still do not get activated.
PTF FuncArr[n] = { this->Func1, this->Func2, this->Func3 };
William
Fortes in fide et opere!
|
|
|
|
|
I can think of two things here:
1) AFAIK you have to put the paranthesis on the pointer before calling:
PS = (*(FuncArr[n]))() (I'm not too sure on the syntax, see MSDN)
your code FuncArr[n] only returns the adress stored in FuncArr.
2) Your Func1() (or Func2() etc) expects a this pointer as a parameter, so you'll corrupt your stack by not having an instantiated object. If you don't want this object you should make your Func's static.
happy hunting
Steen
Cheers
Steen.
"To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
you can do the following;
PTF FuncArr[] = { &CMyClass::Func1, &CMyClass::Func2, &CMyClass::Func3 };
int n = GetDesiredFunc();
CMyClass anObj;
bool retval = (anObj.*FuncArr[n])();
I think that should do the job..
Greetz,
Davy
|
|
|
|
|
How to enumerate pnp devices by their type? Subject of interest - unknown and unsupported devices.
|
|
|
|
|
Perhaps this article from MSDN will be of help. Not really one of my strong points, this one, but happy reading nevertheless: Enumerating Current Devices[^].
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Thank you for you trying to help me, but
this sample enumerates devices with properly installed drivers. I need to enumerate devices of "Unknown" or "Unsupported" type. These devices has no GUID in the system registry, and I guess I can't enumerate them using this SetupAPI. Anyway it seems they are not appeared in the HKLM\System\CurrentControlSet entry in the System registry.
But I can be wrong.
|
|
|
|
|
Construct a reliable and efficient news service for users over a network of computers (with only one news group).
The service:
------------
Every user can connect via a news client to any one of replicated servers.
The news service provides the following capabilities:
1. Login as a user.
The GUI-based client mrn needs to login with a user to perform any of the tasks below. You should allow the client to login as a new user as part of the menu by specifying the user name.
2. Connecting to a server.
The client needs to connect to a server to perform any of the tasks below. You should allow the client to change its server as part of the menu, by specifying the server index. At any point, the client may be connected to one server only. To connect to a server, all a client needs to do is to set this server as its serving server.
3. View list of headers of available messages (The service should distinguish between messages that were already read by this user, and unread messages):
The view should include the user name, the responding server index and list of message headers. The headers in the list will be numbered (1, 2, 3, ...) the header should contain a subject and author.
Each request for a view should result in the most updated information possible.
4. Post a message:
subject: <subject string="">
<msg string="">
The size of the msg string can be bounded to 1000 bytes.
5. Delete a message (read or unread):
Will allow to delete a message from this user's view only, by its number or by pointing on it.
6. Read a message (read or unread):
Will allow the user to retrieve the content of a message by its number.
The message should be marked as read for this user thereafter.
The News Servers:
-----------------
The news client connects to one of the server processes. Each of the server processes is a background daemon. The server may crash and may subsequently recover. The overall set of servers is not fixed. A server is started with its id as a parameter with the command mserver[1-5].
The users must always receive a consistent view of the single news group, regardless of which server is consulted (of course, as consistent as possible, according to the network connectivity).
The view should be consistent as to which messages are available,
have been read or deleted by this user. Each server should save information separately on disk.
A news message should be expired by the system 300 seconds after its creation. After expiration, the message should not be available for users.
At some point after expiration, the message should be deleted without trace to it in the system's data structures (garbage collection).
Crashes of the servers and clients should be managed by a separate program mcrash pid. A crashed server exits the program immediately! it is not legal to write to disk after a server receives a kill signal.
When a server crashes, clients connected to that server will report the loss of connection to the user, so that the user can connect to another server and continue posting/receiving messages.
The users are not known beforehand, and their number is not bounded.
Summary
-------
These are 3 programs:
The client mrn
The server mserver
the crasher mcrash
Requirements
------------
- System produces correct results for all inputs, except those specificly listed as not required.
Deliverables:
-------------
1. Source files (.c not the stubs) and any .h isn't automatically generated by the rpcgen.
2. A listing of execution.
3. Final report.
|
|
|
|
|
Cool homework Sounds more advanced than anything I was assigned for my CS Degree..
Could you be a little more specific about what help you need? It looks like a lot of work, and some of us have to work for a living.
Ryan
|
|
|
|
|
if you can help me with this to not flunk the course, you can ask what ever u need
|
|
|
|
|
1. Thank you for admitting this is a homework question. When people try and hide this we can get irate.
2. Although we would like to help you, its better if you present what you have managed to do so far and where you have got stuck. Being presented with a complete answer circumvents the learning process which we here at CP would like to encourage. There is no better way of learning than getting your feet wet. Once you have paddled around for a while, we will be happy to help you out in deeper waters.
Roger Allen - Sonork 100.10016
If your dead and reading this, then you have no life!
|
|
|
|
|
could you please explain to me the whole idea of this homework in a simple way
thank you
|
|
|
|
|
At first, I would try to find out what kind of objects you actually going to need, and how they are interconnected.
For this you could use UML, but I think this is way too complicated in you case:
Just scribble away from the bottom of your heart, and after a few/lot of/nearly unlimited number of iterations things will get clearer.
You will have at least some idea about how to start the task - Which is what you seem to lack by now.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
i didn't quitely understand what do you mean what kind of objects i am using, but i can tell you that i have to use RTC
|
|
|
|
|
gina78 wrote:
i have to use RTC
Real Time Clock?
Whan I meant was that you did sound as if you need to get a start into your project.
For me, the best way is to draw some sort (all sorts) of diagram to start to get the hang about where to start.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
no, RTC (Remote procedure Call)
attached the initial document ( design ) with the client and server attached. I am still stuck with the posting of the message with the error: rpc cannot enable arguments
question: how can i attach files to you
|
|
|
|
|
gina78 wrote:
I am still stuck with the posting of the message with the error: rpc cannot enable arguments
Now this the first time you ask a precise question. People here are glad to help you out when you ask this kind of questions, but do hate the 'Please do my homework!' style. (As Roger Allen already mentioned)
As for the code: you can simply enter it into the textbox and wrap it in <pre> and </pre>.
For the picture, it might be OK to post a link to a webserver where you have placed it.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
const msgstring_size = 1000;
struct message
{ String usr_name;
String msg;
int svc_index;
int msg_num;
int msg_subject;
String msg_author;
boolean read;
};
struct header
{
String subject;
String author;
};
program clntsvcPROG
{
version clntsvc_pgVERS
{
void login(usr_name) = 1 ;
void connect_svc(svc_index) = 2 ;
void viewlist(void) = 3 ;
void post_msg(msg) = 4 ;
void delete(msg_num) = 5 ;
void read(msg_num) = 6 ;
void start_svc(svc_index) = 7 ;
void msg_exp(msg_num) = 8 ;
void svc_crash(svc_index) = 9 ;
void clnt_crash(void) = 10;
} = 1;
version clntsvc_pgVERS2
{
void delete(int* msg_num) = 1;
} = 2;
} = 0x30090949;
|
|
|
|
|
This is some linux/gcc -c code.
I have no idea how this is working and I can't test it. And, btw. I won't do your homework!
You need to ask specific questions, preferably in another thread, and with a meanigful headline. This way, all people who (unlike me) know about your subject feel invited to help you.
I hope I could help you at least a little.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
Initial design document
« News service application »
1. Program Files
q Files common to both the client and the server
- Makefile : Used to compile the client and the server
- clientserver.x : RPC specification file used by rpcgen
- clientserver.h : Header file generated by rpcgen
- clientserver_clnt.c : Client code generated by rpgen
- clientserver_svc.c : Server code generated by rpgen
- clientserver_xdr.c : XDR conversion file generated by rpcgen
q Client specific files
- mrn.c : Client main program
- mrn_cif.c : Client interface routines
- mrn : Client executable
q Server specific files
- mserver.c : Application server code
- mserver_sif.c : Server interface routines
- mserver : Server executable
q Crasher specific files
- mcrash.c : Application crasher code
- mcrash_cif.c : Crasher interface routines
- mcrash : Crasher executable
2. Makefile
#
# Makefile for news service application (conventional and RPC)
#
all : mrn mserver mcrash
install : all
@echo nothing to install
clean : rm *.o clientserver.h clientserver_xdr.c clientserver_clnt.c clientserver_svc.c mrn mserver
mcrash
#
# Dependencies for files generated by rpcgen
#
clientserver_clnt.c : clientserver.h clientserver.x
clientserver_xdr.c : clientserver.h clientserver.x
clientserver_svc.c : clientserver.h clientserver.x
clientserver.h : clientserver.x
rpcgen clientserver.x
#
# Link client-side files for RPC version
#
mrn : clientserver_clnt.o mrn_cif.o clientserver_xdr.o mrn.o
gcc -o mrn clientserver_clnt.o mrn_cif.o mrn.o clientserver_xdr.o -lnsl
#
# Link server-side files for RPC version
#
mserver : clientserver_svc.o mserver_sif.o mserver.o clientserver_xdr.o
gcc -o mserver clientserver_svc.o mserver_sif.o mserver.o clientserver_xdr.o -lnsl
#
# Link crasher-side files for RPC version
#
mcrasher : clientserver_svc.o mcrasher_cif.o mcrasher.o clientserver_xdr.o
gcc -o mcrasher clientserver_svc.o mcrasher_cif.o mcrasher.o clientserver_xdr.o -lnsl
#
# Individual object file dependencies
#
clientserver_clnt.o : clientserver_clnt.c clientserver.h clientserver.x
gcc -c clientserver_clnt.c
clientserver_svc.o : clientserver_svc.c clientserver.h clientserver.x
gcc -c clientserver_svc.c
clientserver_xdr.o : clientserver_xdr.c clientserver.h clientserver.x
gcc -c clientserver_xdr.c
mrn.o : mrn.c clientserver.h clientserver.x
gcc -c mrn.c
mrn_cif.o : mrn_cif.c clientserver.h clientserver.x
gcc -c mrn_cif.c
mserver.o : mserver.c clientserver.h clientsserver.x
gcc -c mrn.c
mserver_sif.o : mserver_cif.c clientserver.h clientserver.x
gcc -c mrn_cif.c
mcrasher.o : mcrasher.c clientserver.h clientserver.x
gcc -c mcrasher.c
mcrasher_cif.o : mcrasher_cif.c clientserver.h clientserver.x
gcc -c mcrasher_cif.c
3. RPC specification file
const msgstring_size = 1000;
struct message
{
String usr_name;
String msg;
int svc_index;
int msg_num;
int msg_subject;
String msg_author;
boolean read;
};
struct header
{
String subject;
String author;
};
program clntsvcPROG
{
version clntsvc_pgVERS
{
void login(String) = 1 ;
void connect_svc(int) = 2 ;
void viewlist(void) = 3 ;
void post_msg(String) = 4 ;
void delete(int) = 5 ;
void read(int) = 6 ;
void start_svc(int) = 7 ;
void msg_exp(int) = 8 ;
void svc_crash(int) = 9 ;
void clnt_crash(void) = 10;
} = 1;
} = 0x30090949;
The first procedure is used to login as a user
The second is to connect to a server.
The third procedure is to view list of available messages.
The fourth procedure is for posting messages.
The fifth procedure is for deleting messages read or unread.
The sixth procedure is for reading messages.
The seventh procedure is to start the server.
The eighth procedure is to handle the expiration of messages.
The ninth procedure is to handle crashing server.
The tenth procedure is to handle crashing client.
4. Running the program
To start the server application, enter: mserver
To start a client application, enter: mrn [hostname]
|
|
|
|
|
#
# Makefile for example bank application (conventional and RPC)
#
all:
client server
install:
all
@echo nothing to install.
clean:
rm *.o clientserver.h clientserver_xdr.c clientserver_clnt.c
clientserver_svc.c client server
#
# Dependencies for files generated by rpcgen
#
clientserver_clnt.c: clientserver.h clientserver.x
clientserver_svc.c: clientserver.h clientserver.x
clientserver_xdr.c: clientserver.h clientserver.x
clientserver.h: clientserver.x
rpcgen clientserver.x
#
# Link client-side files for RPC version
#
bank: bank_clnt.o bank_cif.o bank.o bank_xdr.o
gcc -o bank bank_clnt.o bank_cif.o bank.o \
bank_xdr.o -lnsl
#
# Link server-side files for RPC version
#
server: clientserver_svc.o clientserver_sif.o clientserver_srp.o
clientserver_xdr.o
gcc -o server clientserver_svc.o clientserver_sif.o
clientserver_srp.o \
clientserver_xdr.o -lnsl
#
# Individual object file dependencies
#
clientserver.o: clientserver.c clientserver.h clientserver.x
gcc -c clientserver.c
clientserver_clnt.o: clientserver_clnt.c clientserver.h clientserver.x
gcc -c clientserver_clnt.c
clientserver_svc.o: clientserver_svc.c clientserver.h clientserver.x
gcc -c clientserver_svc.c
clientserver_xdr.o: clientserver_xdr.c clientserver.h clientserver.x
gcc -c clientserver_xdr.c
clientserver_cif.o: clientserver_cif.c clientserver.h clientserver.x
gcc -c clientserver_cif.c
clientserver_sif.o: clientserver_sif.c clientserver.h clientserver.x
gcc -c clientserver_sif.c
clientserver_srp.o: clientserver_srp.c clientserver.h clientserver.x
gcc -c clientserver_srp.c
|
|
|
|
|
i have here the initial design, but how can i attached it so you can see my work , and help me through this
thank you
|
|
|
|
|
halloo all , is there any one have a VC++ code for taking a video from computer camera and store the video data in any video format(.AVI,.mpg,...etc) while still i can take the video data,process it and store it againe and play it if i want .help me please.
thanks fore any help.
|
|
|
|
|
Get a copy of the directshow SDK. I think that it is now part of the main DirectX SDK. Have a look at the AMCap sample application, should get you started.
Ryan.
|
|
|
|
|
|
Hi,
I'm having problems with the CMenu class and was hoping someone would be able to help. The problem is that the CMenu class is modal and therefore stops the rest of my application from running whenever a menu is opened. This is a problem because every program cycle I look at a comm port and read in whatever is in the port. If someone leaves the menu open the buffer fills up and I have to resynchronise with the external hardware. Is there a way to make the CMenu class act in a non-modal way or is there a way to handle the comm port (without using threads preferably)?
I'm using Visual Studio 6.0 and am using the MSComm ActiveX control to communicate with the comm port.
Thanks in advance,
Phil
|
|
|
|