-
GUI App Question ??
I am working on a project with some friends where I'll be coding the GUI in Windows, of course. My friends are doing the backend functions in Visual C++. What I'm trying to decide is what is the quickest, easiest and best app to use for building a nice GUI that will easily integrate to their libraries?
I need something that will take me no more than a month or so to do the interface but it has to be compatible with the other functions. I know some C and I've used VB before. I definitely do not want to use VB this time so I am leaning towards Borland C Builder. I have no real experience with the Windows api or mfc or whatever so coding by hand, I think, would take longer than needed.
What do you think? Do I have any other options besides C Builder? Has anyone had any issues using C Buider and VC++ together before?
Thanks.
-
I would suggest that you write the font & back ends with the same compiler.
Borland C++ Builder is a good choice for building the GUI. It is also complient with standard C++ and compatible with MFC, COM, ActiveX. There ain't nothing you can do in VC++ you can't do in BCB.
So if your mates write the backend in standard C++ (say as a set of functions and/or objects), you should be able to compile it under Borland all in one application. This removes almost all interface issues. The only ones you will encounter are things like how to get an AnsiString object into a function which takes char*. But such issues are trivial (use c_str() in AnsiString).
Otherwise, I assume we talking about the backend as DLL. If you were to compile the backend in VC++ & the front end in BCB, then interfacing them is perfectly possible. However, you will have to overcome a number of issues, including calling convention, loading of the VC DLL, function name decoration. If you adopt this approach, then I suggest the backend interface does NOT involve objects (use flat functions only), OR you interface using COM.
-
I recommend Visual C++ because Microsoft development tools are more optimized for Windows OS than CBuilder.
Kuphryn
-
>I recommend Visual C++ because Microsoft development tools are more optimized for Windows OS than CBuilder.
Eh? I don't want a compiler war, but that's just ad-speak rubbish.
Are you suggesting Borland implements something like:
Code:
HWND FindWindow(LPCTSTR lpClassName, LPCTSTR pWindowName)
{
// Borland Wrapper around FindWindow
// Pointless sleep
Sleep(100);
// Now call real win api function
return winuser::FindWindow(lpClassName, pWindowName);
}
-
I'm looking for the best in terms of performance, ease of integration with VC and, most importantly, time to complete. Please compare these three among the options. E.g., performance = VC by a little, integration = VC by more, time to complete = C Builder by a lot ... or something like that. Given the above situation, I would go with C Builder.
-
You sound like a manager :). Is this what you want?
BCB---------
Performance : High
Integrating BCB GUI with VC DLL: Hard
Integrating BCB GUI with BCB DLL : Easier than above
Ease of Creating GUIs using BCB VCL : Easy
Ease of Creating GUIs using MS API/MFC : Hard
VC---------
Performance : High
Integrating VC GUI with BCB DLL : Hard
Integrating VC GUI with VC DLL : Easier than above
Ease of Creating GUIs using BCB VCL : Not an option
Ease of Creating GUIs using MS API/MFC : Hard
-
Well, soon I'll be releasing "Hilo", a Windows class library which is designed for rapid application development. I've used an older version of it for quite a while now, and I am very pleased with it. With Hilo, (pronounced 'HEE-LOW'), you could certainly write a sophisticated Windows application in less than a month. Still, I won't release it until I test it extensively, so probably by the first of November...
Email me if you're interested, and I'll keep you posted.
-
I write GUI's for comercial apps with the pure WIN32 API using MS Visual Studio.
If you are using Visual C++ for the back end, use it for the front end and eliminate compatibility and cost issues.
If you know C++ use MFC rather than pure WIN32 API or it will take longer than a month for a complex GUI (unless you are very competent). A basic app skeleton can be created in minutes with MFC. (a day in pure WIN32 API if you know what you are doing)
What I would call a complex GUI would take more than a month no matter what (before it was FULLY tested).
-
Well certainly I wouldn't place such a time-frame on myself. But in my view, the majority of the programming should be focused on the algorithms and data structures, the back-end . Still I admire your willingness to use pure API and it only exemplifies the outstanding coder that you're so well known to be ( just ask around ;) ). I always liked programming console apps because of the emphasis on the utility of it, and after moving on to Windows, quickly decided I would like to use a "visual" environment to produce the bulk of the GUI in order to continue enjoying that utilitarian programming style. While I haven't reached the visual aspect quite yet, I have come close to the source code version. Here is a small example of Hilo in action.
Code:
class Winnie : public MainWindow {
public:
void NotifyMe() {
Beep(10, 10);
}
Winnie() {
Register(&Winnie::NotifyMe, WM_LBUTTONUP);
}
}; //...we here 'beep' when user releases left clicker over main window...
Winnie win;
//..tight coupling, class accesses a global variable "win"...
class Button1 : public Button {
public:
void BeepWinnie() {
Send(win, WM_LBUTTONUP);
}
Button1() {
Register(&Button1::BeepWinnie, WM_LBUTTONDOWN);
}
}; //...we here 'beep' when user clicks a button of this class...
//...now use loose coupling...
class Button2 {
public:
Button2() {
Register(&Button2::BeepStranger, WM_ONMOUSEHOVER);
}
void BeepStranger() {
Broadcast( WM_LBUTTONUP ); //..send to "attached" observers...
}
}; //...we get a 'beep' when user hovers over this button...
int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int visibility) {
ScreenMax max; //...thin encapsulation of SM_CX/CY retrieval...
win.SetWidthHeight( max.x/2, max.y/2 );
win.Center();
win.Create("Hello World!", DefaultWindowStyle(), visibility);
Button1 b1("Tight", max.x/10, max.y/10);
Button2 b2("Loose", max.x/10, max.y/10);
//...create two side-by-side buttons...
b1.BottomRight( b1.Center( win.Center() ) ); //...'bootstrap' alignment ;)
b2.BottomLeft( b2.Center( win.Center() ) );
win.Observe( b2 ); //...recieve b2's Broadcast's()...
return win.RunMessageLoop();
}
As you can see, we're back to programming in main(). Gone is the ugly WindowProcedure. No more fishing for HWND's. Just an easy to use interface that hides so many of those ugly implementation details, without compromising the API itself ( for instance, GetDC( win() ) would be a valid call...).
Having said that, though, all Windows programmers should know straight API, if not just to understand how the whole convoluted (but fascinating) mess works. :)
-
If you want to "drag and drop" your GUI, BCB, in my experience, is faster and easier to learn than VC. I have never had problems mixing BCB and VC but I know some have.
Given the time constraints and your unfamliarity with the API, I would not recomend that path, (although if the time permits, I would always advocate learning the API before a class library).
As Novacain has pointed out, a sophisticated working GUI would take more than a month using any tool.
