|
OK, my reasoning behind using c++ is that it is the only programming language in which I have any experience at all, I have never used Flash, but if it were something I could puzzle out with a basic knowledge of c++ I would be willing to give it a try.
Also, checked out howstuffworks.com, and that is not really what I had in mind, I want a GUI app that will allow somone to set up an electrical circuit(s). I then want to be able to emulate how that circuit would function under given conditions with a variety of variables. I don't necessarily want to have highly detailed graphics, the ability to manipulate variables is more important. (for instance, building a 120 volt system, then introducing a condition that creates a current overload, or changing the voltage and emulating all the resultant breakers tripping, appliances frying etc.) Can this type of variable manipulation be done with Flash?
|
|
|
|
|
FYI, Just about anything can be done with any tool. If you don't think so, you just haven't figured it out yet.
What I would do if I were you is to start with a graphical app first (VC, using a SDI interface and a docking toolbar) and do the drawings yourself. Not only is this a good intro to drawing on a surface, it will allow you total control of the schematics. Just create a base class called CircuitElement that has a CRect position variable and a virtual Draw() function. Then, derive classes from CircuitElement that override the draw function to draw the specifics of an element. EX:
class CircuitElement : public CObject
{
protected:
CRect m_oPosition;
public:
virtual void Draw(CDC *pDC); // just erase the bkgrnd
virtual void Serialize(CArchive &ar); // save the pos
};
class Outlet : public CircuitElement
{
protected:
amp rating...
etc...
public:
virtual void Draw(CDC *pDC); //call base and draw |=|=|
virtual void Serialize(CArchive &ar);
}
|
|
|
|
|
go with a MFC application right now, you can make a UI fast enough for you to concentrate on the core of the application.
there are 2 important things ( that I see, you can correct me if I'm wrong ) to do, first is the building layout, how will it be presented, will it be only 2D (one floor at a time, with links to pass wires to other floors ), or will it be a 2D1/2 one floor with other floors in transparency, a bit like some architectual plans. or will it be fully 3D with navigate; for the first 2, vector graphics can be easier to work with, or simple GDI graphics, for the 3d, either OpenGL or DirectX
the other thing is to define the electrical layout, switched, fuse boxes, wires, grounds; all the design should be graphic independant, you should be able to define an electrical layout without the need of graphics (i.e. roughly, switch in room X connected to ... )
Everything can be as simple as having simple geometric symbols for each time, all connected with lines, to the more elaborate 3d models to the in-between with bitmaps for each component.
Hope it helps.
Maximilien Lincourt
For success one must aquire one's self
|
|
|
|
|
How can i add push buttons instead of check boxes to items in the first coulmn of a ClistCtrl?(Report Type)
Is there any simpler way of doing it without handling OnDrawItems()?
Thanks,
harendra
Haren
|
|
|
|
|
For some reason I get error when I try to call a funtion in another class/file.
Here is what I am doing:
I have written a program that accesses a PCI card and performs functions on that card.
Everything wroks fine when I call these functions from myMainFile.cpp
In that file I have included the pciFunctions.h
I need a class that calls these functions performs tasks on the data and returns the data to the myMainFile.cpp
I need to do this so that I can display the values in various widgets.
so I created a new header file and created a class.
#ifndef rfmAccess_H
#define rfmAccess_H
#include pciFunctions
//other standard includes
class RFMAccess{
private:
public:
RFMAccess(){}
int openCard(char *devPath); //this is the function prototype
};
#endif
*************In myMainFile.cpp***************
#include "rfmAccess.h"
//I created a pointer to the class
RFMAccess *RFMAccess;
Then I call the function.
TmyMainFileForm1::Action1Execute(TObject *Sender){
RFMAccess::openCard("////.//RFM1");
or
RFMAccess.openCard("////.//RFM1");
or
RFMAccess->openCard("////.//RFM1");
}
Should I create the function in the rfmAccess.h or should I create another *.cpp file and do it in there?
Do I have to create a prototype or can I just finish the function in the rfmAccess.h file
Am I doing this right?
Am I calling the function correctly?
Sorry for so many questions, but I need alittle help. 
Thanks,
steven
|
|
|
|
|
johnstonsk wrote:
Should I create the function in the rfmAccess.h or should I create another *.cpp file and do it in there?
Technically you could do either, but most of the time you will want to create a .cpp file corresponding to your .h file and define the function there.
johnstonsk wrote:
Do I have to create a prototype or can I just finish the function in the rfmAccess.h file
See answer above. Small technical point: what you have in the header file already *is* the prototype.
johnstonsk wrote:
Am I calling the function correctly?
If you are calling the function via a pointer, then you'll want to use lpRFMAccess->openCard("////.//RFM1");. If you are calling the function from an object you'll want to use oRFMAccess.openCard("////.//RFM1");.
There are some other problems with your code above:
When you define a pointer to the RFMAccess class, you need to give it a valid name. You have written RFMAccess *RFMAccess; -- give the pointer a name other than the class name like this : RFMAccess *lpRFMAccess; Also, when you use a pointer, make sure it is valid. The way you have your code, the pointer is never made to point to a valid RFMAccess object, thus trying to call a function via your pointer will probably crash your program.
--Dean
|
|
|
|
|
Thank you, very helpful and it makes sense.
You mentioned:
most of the time you will want to create a .cpp file corresponding to your .h file and define the function there.
what is the purpose of creating a prototype and then defining the function in another *.h file when you can do it all in one shot?
Just wanting to be a better programmer.
Thanks, steven
|
|
|
|
|
It removes clutter for one. Your header should be as clean as possible. Think of it as a reference for the functions that are contained in the class. If you can't remember how to call a function, you open up the header and find the prototype -- all that extra code in the file makes that task more difficult.
The other (more important) reason for separating the two is known as "separating interface from implementation". Say you write a class and someone else wants to use it later on. They don't need to know how your class works -- only that it does the job you say it will. It keeps things simple for everyone -- it's basically another layer of abstraction.
Plus, if you don't want anyone to see your source code for whatever reason, you can give them the header file and a compiled library to link against and they won't be able to tell how you did what you did with your class (at least not without a bit of extra work.) Then if you change your implementation later on (say for instance you find a faster algorithm for one of your functions) all you have to do is compile a new version of your code library and give it to your users. Then rather than having to recompile their whole program, your users only need to relink their application to your new library rather than recompiling their whole program.
Hope that all makes sense.
--Dean
|
|
|
|
|
very informative,
thanks for the knowledge.
steven
|
|
|
|
|
Is there a web page with a complete listing of Windows Messages and their values?
-Nick Parker
|
|
|
|
|
Try looking in WinUser.h or some of the other header files.
There are 10 kinds of people - those that get binary and those that don't.
|
|
|
|
|
Miszou wrote:
Try looking in WinUser.h or some of the other header files.
I was wondering if the was a website with these listed though, thanks.
-Nick Parker
|
|
|
|
|
You can use the API Text Viewer that comes as part of Visual Studio.
|
|
|
|
|
I use an Object of SplitterWnd class and divide the frame to three view,so how can get one of three views any where .
Thank you !
abc
|
|
|
|
|
One solution is via the pane.
CTheView *pTheView = static_cast<ctheview *="">(m_SplitterWnd.GetPane(...));
Kuphryn
|
|
|
|
|
Must I ship the same .h file that I've just used to compile a .DLL with classes with this .DLL?
I mean: I don't want to let others view/know what private/protected methods/attributes I've used. Could I use a "reduced" .h file with only public methods/attributes?
Thanks in advance
__________________________
Fernando de Francisco Cano
__________________________
|
|
|
|
|
|
If you want to ship .H files with a DLL, without giving away any information about what's really in there, the "PIMPL" thing does the trick. Though it's slightly more involved than just shipping a header.
You end up creating 2 headers:
(1) An interface. A header for the public name of your class and public API's in this class. It describes the structure without the meat.
(2) The actual class header, which defines all the stuff, the data, other public and private methods, yada yada yada. This class header also subclasses the interface class. This is referred to as the "implementation".
You must also create a factory method to create your class. It's not acceptable to let the consumer of your DLL do a "new MyClass". This is because the header that you ship him represents only an interface to the class that get's instantiated, and not the actual class.
You must also create a mechanism of destruction. Since the class was created with a factory, and possibly from a different heap than yours -- YOU MUST tell the class to destroy itself. My favorite easy way is to put a virtual "DeleteThis()" method on it.
Here's a quick sample -- in one possible way. (this doesn't match PIMPL exactly -- what an awful name!) But it shows some of the details:
MyClass.H
------------------
class __declspec(dllexport) MyClass<br />
{<br />
public:<br />
virtual int Function1() = 0;<br />
virtual int Function2() = 0;<br />
<br />
virtual void DeleteThis() = 0;<br />
static void MyClass* New();<br />
};
------------------
MyClassImpl.H
---------------------
class __declspec(dllexport) MyClassImpl : public MyClass<br />
{<br />
public:<br />
virtual int Function1() { do something; }<br />
virtual int Function2() { do something else; }<br />
virtual void DeleteThis() {delete this;}<br />
int m_MagicDataThatNoOneCanSee;<br />
<br />
int MagicFunction();<br />
};
---------------------
MyClassImpl.CPP
---------------------
MyClass *MyClass::New()<br />
{<br />
return new MyClassImpl;<br />
}<br />
.....
---------------
---------------------
The gist of this -- is that you hand out interfaces ONLY. The guts that implement the interface can change at will.
This is also one of the foundations of how COM stuff is implemented. They export everything in COM the same way..... With the use of COM you can even play tricks, like creating implementations that actually serve up multiple interfaces.... but's that's another story.
This way of doing things is great. It offers you a lot of flexibility and safety in creating API's!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
Santa Cruz Networks
|
|
|
|
|
I am currently writing a program to convert an ascii text file into upper/lower case text. The file contains names and addresses, the problem I am having is on the name field. I need to identify if the name is a "special case", ie MR JOHN O'BRIEN -> Mr John O'Brien. There are many examples where this sort of thing happens, can anyone suggest a way of identifying these cases?
Brian Reffold
Programmer
Brown Knight & Truscott
|
|
|
|
|
You're right. I don't think I need transparency at all costs. But it's quite interesting problem, so I'd like to resolve it 
-bda-
|
|
|
|
|
You might have to draw your window into a memory device context (not an easy task), and then use AlphaBlend() to draw it with transparency to the screen, but you'll probably need to use multiple AlphaBlend() calls so that you can leave out areas that you don't want transparent. Then draw the non-transparent areas using a simple BitBlt(). A fairly complex thing to do, but I can't see another way of doing it. I would just stick to making the whole window transparent  .
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
I have created an application that need to fill the screen.
I am able to do it with 1024x768 , but I need it to size correctly if they have their display set to a higher resolution.
i.e 1200x1600 etc.
Does anyone know of a way to do this?
Possibly accessing a systems settings and then using the values returned to set the size of the application.
thanks,
steven
|
|
|
|
|
You can display the window maximized. You don't need to know the actual screen size.
ShowWindow(SW_MAXIMIZED) instead of ShowWindow(SW_SHOW)
-----
We are what we repeatedly do. Excellence, then, is not an act, but a habit.
|
|
|
|
|
That's the easy way most of the time .
I took the view that he wanted to "fill the screen" - including the taskbar area, hence my reply below.
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
If you only want it to work with a single-monitor system, then using GetSystemMetrics() with the SM_CXSCREEN and SM_CYSCREEN indexes will give you the width and height of the screen.
If you want it to work with multiple monitors (highly recommended), then it's a bit more complicated. Use EnumMonitors(). Something like this, called from inside your one of your window's functions, probably OnCreate():
BOOL CALLBACK monitorEnumProc(HMONITOR hMonitor, HDC hdcMonitor, LPRECT lprcMonitor, LPARAM dwData)
{
if(hMonitor != NULL)
{
CWnd *pWnd = (CWnd*)dwData;
if(pWnd != NULL)
pWnd->MoveWindow(lprcMonitor);
}
return TRUE;
}
int CMyWnd::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
...
CDC *pDC = GetDC();
EnumMonitors(pDC->GetSafeHdc(), NULL, monitorEnumProc, (LPARAM)this);
ReleaseDC(pDC);
...
}EnumMonitors() will call the callback function once for every monitor that the specified device context (taken from your window) is on, which may be more than one. However, Windows always creates a top-level window such that it never spans more than one monitor, so from OnCreate() it should only call the callback function once. You can guarantee it's only called once by returning FALSE from the callback function instead of TRUE, if you want to.
Hope this helps. I haven't tested this code, but I've done it before (I just hope my memory is correct )
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
