|
Member 11018967 wrote: when i do CDialog::oninitdialog it runs perfect but no with CDHtmlDialog::oninitdialog()
That does not really tell us anything about the problem you are seeing. Please edit your question and add full details of what is going wrong.
|
|
|
|
|
My Question is that How we can use CHTMLEditView with DHTMLdialog at specific rect width and height.. When i create HTMLEDITCtrl/CHtmlView in DHTMLDialog it does not edit the text it becomes freeze..
How i can use CHTMLView in DHTMLDialog. Just want to make HtmlEditor that has buttons and backend UI is in HTML.
|
|
|
|
|
Member 11018967 wrote: it does not edit the text it becomes freeze..
This still does not tell us anything useful. If you want someone to help you then provide a proper detailed description of what your code is doing and where the error(s) occur.
|
|
|
|
|
Visual Studio 2008, c++
Class C_Messages works with various structures called messages. The initial configuration of the messages is by reading a text file and is rather extensive. C_Messages instantiates a class called C_Configuration to read the text file and perform all the startup work. Currently C_Messages instantiates C_Configuration then calls some functions handing C_Configuration pointers to the structures.
Is there some way that C_Configuration can be declare a friend of C_Messages and dispense with the functions just to set the pointers. I am thinking of something like this in C_Messages.h
Class C_Configuration;
Class C_Messages
{
…
Friend C_Configuration;
int x;
}
Then in file C_Configuration.cpp would be something like:
Class C_Messages
Int Do_This()
{
X = 2;
}
When I read the various forum questions on this none seem to apply to a simple relationship like this. Maybe its just not possible so I am trying make a simple question out of this.
EDIT
I just figured out part of it and why the compiler is saying the variable is not static. If I don't want static variables can I do something like hand over the this pointer to C_Messages to C_Configuration then C_Configuration can access the members of C_Messages?
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
modified 9-Dec-14 14:09pm.
|
|
|
|
|
What you have shown above doesn't really make sense. The use of the friend keyword is to allow access to protected or private variables of the other class, but you still need an instance of the class to access them. It's most useful when the friend class inherits the other one. If you are just interested in accessing the properties or methods of an object of another class, then you should make them public.
|
|
|
|
|
Re: Quote: The use of the friend keyword is to allow access to protected or private variables of the other class
That is the part I thought I understood.
Quote: but you still need an instance of the class to access them.
That is what I have now figured out, but I think only partially.
Quote: It's most useful when the friend class inherits the other one
Is the intent most useful or only useful. I am thinking only. I was thinking friend had a rather broader scope.
Class M starts running and creates class C to do a bunch of startup work. C is owned by M but does not inherit from M. C is deleted immediately upon completing its work.
Other than for startup (which requires some 80,000+ data items from a file), nothing in M needs to be public. But this entire app is and always be run in a closed system with strictly controlled ins and outs. I am leery of public variables but that would probably better than sending over a flock of pointers. Does the use of public seem to be my best option.
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
|
|
|
|
|
bkelly13 wrote: Class M starts running and creates class C to do a bunch of startup work. C is owned by M but does not inherit from M. C is deleted immediately upon completing its work.
Then there is no need for them to be friends.
bkelly13 wrote: I am leery of public variables
You can hid the variables by making them private, and creating public methods to get or set them, which is the generally recommended pattern in OOP.
At the end of the day it all depends on what each of your classes is supposed to do.
|
|
|
|
|
If all instances of C are owned by and created by an instance of M and there are no other clients of C then I can't see a lot of problem in making M a friend of C. You're essentially saying that C is a part of M you don't need all the time so you want to tear it off and discard it after some initialisation process.
Another way of doing it would be to introduce a new class, A that contains the bits of M that C needs to manipulate. M would contain an instance of A and pass a pointer to the instance to C when needed. That gives you a bit more future proofing and decoupling - both C and M don't depend on each other and just depend on A.
Yet another way would be to have a getter/setter interface on M but if C's the only thing that would want to use it then you're complicating the interface of M for no real reason.
Personally I'd go for the first and consider the second or third later if the requirements change and you need more flexibility.
|
|
|
|
|
First option was: Quote: then I can't see a lot of problem in making M a friend of C.
I was thinking that C would be a friend of M allowing C to see into M. Am I thinking wrong on that.
What is the syntax to make this declaration? C gets access to the variables of M, can change them, then C gets deleted.
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
|
|
|
|
|
You're right - I got things a bit bum backwards. Basically you want C to be able to look at the implementation details of M so you declare C a friend in M:
class M
{
friend class C;
};
should do the trick.
|
|
|
|
|
friend can be used to give another class access to the protected and private members of the class that specified friend.
If C_Messages want to access the protected and private members of the class C_Configuration then C_Configuration specified C_Messages as friend.
If you aggregate the class C_Messages so that is has a C_Configuration, you can only access the public members of C_Configuration in C_Messages. But with the friend specifier you can also access the protected and private members.
Sample code:
class C2;
class C1
{
public:
int public_var;
protected:
int protected_var;
private:
int private_var;
friend class C2;
};
class C2
{
public:
class C1 member;
void set_private_var (int v) { member.private_var = v; }
void set_protected_var (int v) { member.protected_var = v; }
};
void Test()
{
C2 obj;
obj.member.public_var = 100;
obj.set_protected_var(100); obj.set_private_var(200); }
Another solution is working with an intermediate class which specifies the friend. In this case you get only access to public and protected members of the base class.
Sample code:
class C1
{
public:
int public_var;
protected:
int protected_var;
private:
int private_var;
};
class C1B : public C1
{
friend C2;
}
class C2
{
public:
class C1B member;
void set_protected_var (int v) { member.protected_var = v; }
};
void Test()
{
C2 obj;
obj.member.public_var = 100;
obj.set_protected_var(100); }
modified 5-Jan-15 6:07am.
|
|
|
|
|
I am having one DLL file. when i crack that it becomes breakable and we can see the codings of that DLL in visual studio. but, i need that DLL as unbreakable(i.e., when trying to break that DLL it becomes a error report). If anyone know the answers, Please let me know. Thanks in Advance.
|
|
|
|
|
Google for "C# obfuscation". It is not totally unbreakable but it's about the best you can do.
Also please use the correct forum in future.
|
|
|
|
|
A transition from VS2008 to VS2012 has prompted some re-factoring.
I am the only one in my small group that writes in C++ or with OOP. My “plus plus” skills are self-taught with no opportunity for peer-to-peer discussions. Please forgive me for asking dumb question and give some basic guidance here. I do have rather significant skills in number crunching and handling high data rate non-OOP programming.
I am developing my TCP/API skills with a Server side all and a client side app. These will use the windows TCP/API with non-blocking and overlapped operations. To that end I envision the two classes:
C_TCP_API_Server
C_TCP_API_Client
But there is much functionality that is common to both classes, such as creating the sockets and setting their characteristics. I envision something like:
C_TCP_API_Core
This is to contain most or all of the low level API calls and all the error handling that goes with that.
That changes the first two classes to be:
Class C_TCP_API_Server : public C_TCP_API_Core
Class C_TCP_API_Client : public C_TCP_API_Core
This is the first time I have considered using inheritance. Code efficiency overrides simplicity.
Is this the right way to go?
Should the core class be abstract? Or would that be getting a bit advanced for me.
BTW: I Put the API in the class names to indicate that this code goes as close to the Windows API and the lowest level code I can get. I want the minimum overhead between the code I wrote and the OS (Operating System). It will be handling high and continuous data rates.
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
|
|
|
|
|
my 0.02c worth
if you're comfortable with inheritance, abstraction etc - or want to learn and get comfortable, why not ?
otoh, Ive seen plenty of implementations that are basically C_TCP_API, that have both a client and a server 'listen' method - since they share 90% common code, I see no issue there, either
There will be the purists who will argue left right and center about maintainability, separation of concern, yada yada, fine - Im a pragmatist a) make it work, b) make it pretty and maintainable
|
|
|
|
|
client && server versus client || server, good point. I hadn't thought on that much. I tend to go the separate route for simplicity but will consider more.
Thanks for taking the time to reply.
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
|
|
|
|
|
btw, saw your issue with the IPAddressControl below
the difference between the IPAddressControl and the NetAddressCOntrol is, that the IPAddressControl will only handle IPV4 tcp/ip addresses, while the more complicated NetAddressControl will handle IPV4, IPV6 and DNS type addresses, BUT NEEDS TO BE TOLD which one its dealing with, with its 'SetAllowType' Method
Other than that, they should work almost the same - http://msdn.microsoft.com/en-us/library/bb399237.aspx[^]
'g'
|
|
|
|
|
Re IP versus NET, I had not recognized that difference, and it immediately explains much. I work in the arena of telemetry systems who are probably completely exclusive groups, meaning their systems are closed off from the public world. I will stick with the IP4 through the completion of this project, at least the first version, then see about re-visiting.
Thanks for recognizing that and taking the time to reply.
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
modified 9-Nov-14 12:10pm.
|
|
|
|
|
bkelly13 wrote: This is the first time I have considered using inheritance. Code efficiency overrides simplicity.
Is this the right way to go?
Should the core class be abstract? Or would that be getting a bit advanced for me.
Sure why not? ...if there is enough overlapping code that needs to be written, it makes sense to use a common base class, after all that's the point of inheritance.
If you want to see how somebody else has done something similar, check out the Practical Sockets[^] library. As a matter of fact, that library may already be doing what you're doing...
|
|
|
|
|
Thanks for the comment and the link.
I am doing this as self guided education and for use at work. The main app will start a function as a thread and that will instantiate the TCP class and start a method in the TCP/IP class to conduct all the I/O. That method will run until completion. The entire app is a high data rate telemetry system.
I have divided the send and receive into two separate paths, one to send and one to receive. Each path is a strict producer and consumer link. That tremendously reduces the complexity in communications between the main and the TCP thread. Its almost trivial.
At the lowest level, the TCP class starts a completion thread for the send side and soon will start another completion thread for the receive side.
All the TCP code is driven by events, no polling.
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
|
|
|
|
|
bkelly13 wrote: At the lowest level, the TCP class starts a completion thread for the send side and soon will start another completion thread for the receive side.
I hope you're not literally starting a thread... that's actually a VERY slow process. If you have worker threads that do the same thing over and over again, it's best to start the threads once and leave them around until they're no longer required. You can use the thread pool concept if you need several worker threads instead of just one or two per IO.
Also, depending on the bandwidth, TCP/IP isn't the fastest thing in the world. I doubt telemetry can produce bandwidths high enough to cause a problem but if you start seeing backups, keep in mind that you're paying for the overhead involved in TCP/IP.
|
|
|
|
|
Yes, I mean start a thread. Clarification will be helpful. On start up the main app will create/instantiate the class that handles all the TCP/IP communications. That is separate thread from main. That class will create a separate thread just for the send completion events and another for the receive completion events. After all that is done, then the system is ready to process data. The threads all run until main app is shut down. There is no dynamic thread creation and destruction while moving data. This app uses overlapped I/O and completion events.
Why create two more threads? Because I discovered that a thread that did nothing but handle the send completion events would be rather simple. The breakout of that code from the TCP/IP class into the thread did much to simplify the TCP class that communicates with main and controls the details of the TCP/IP link. Then it was just a small step to do the same with the receive side.
TCP is the only method we have to transfer data between computers. Our display system only accepts data via TCP/IP. Our mission system is contained within a single room and the Ethernet bandwidth is 1Gbps. And for this particular link there is a dedicated port on the send and receive computers that carries nothing but the telemetry traffic.
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
|
|
|
|
|
bkelly13 wrote: TCP is the only method we have to transfer data between computers. --------------------------. Our mission system is contained within a single room and the Ethernet bandwidth is 1Gbps.
Those statements are contradictory... the presence of Ethernet does not imply TCP/IP. There are different protocols that can be used over Ethernet (even raw Ethernet). Some, like TCP/IP, are built for error checking... some are built for speed.
bkelly13 wrote: Our display system only accepts data via TCP/IP.
Typically a GUI display and any other processing are completely independent of one another.
|
|
|
|
|
I stand corrected. The display system is provided by Symvionics and it only accepts data via a TCP/IP connection.
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
|
|
|
|
|
In my client and server classes never inherited a common base class. They just used some common components/classes like a socket class, whatever. Often its cleaner and more correct to use composition than inheritance. Over-generalization is usually a bad thing that should be resolved later. I refer with this to the "Core" base class here. I guess "Core" here means a lot of things and you create an "is a" relationship with inheritance between Server and Core and between Client and Core, so basically your server "is a" set of a lot of things that means chaos. In case of simple programs its OK to have not so nice design but if you want to do it correctly then try to isolate components and features that can be correctly named and encapsulated into a class (like Socket). In my networked programs other components that often come to the scene are "Connection", "Channel", "Server-SideClientHandler" or whatever. So instead of inheriting from a common base class I think here its usually nicer to isolate common things into classes and just using those classes from both the server and the client. If I inherited from a common base class in this case than it would probably be a CApplication class or something similar in case of using a framework...
Another little note related to naming convention (although this is a matter of taste): When I have complex names like C_TCP_API_Server I usually remove parts of the name and use them as namespaces. For example in case of C_TCP_API_Server I would probably use a C_Server class that is inside a TCP_API namespace. This is however just style, its up to you how to name and organize things your code. I've already worked on codebases where the usage of namespaces was forbidden as part of the coding conventions.
/off
Fun fact: In my experience the most dangerous classes in object oriented code often have these names: Something-"Manager", Something-"System", Something-"Handler", Something-"Core", ... 
/on
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
