|
It is quite possible to build complete Windows applications using either tool, Visual Basic or Visual C++. That's what they were designed to do. VC++ is harder to learn, but it also offers far more control over the target platform. VB is simple to learn, but it hides much of the detail from you and makes it simple to fall into sloppy coding habits. Borland has made excellent products in the past, but I haven't used any of them in 10 years or so. Which product you use is a matter of personal taste, but I suspect that you'll have fewer hassles using products made for Windows programming by the folks who make Windows.
As for sites that offer assistance and code samples, you can't do better than this one. Pick a language and start reading through the articles under that heading. You would also be well advised to pick up a couple of books on the language you choose to learn. Microsoft documentation is adequate for reference and quite complete, but it's useless and overwhelming for learning.
Heard in Bullhead City - "You haven't lost your girl -
you've just lost your turn..." [sigh] So true...
|
|
|
|
|
Most excellent synopsis by Antti and Roger 
May I add one thing. If you are wanting to learn Visual C++ ... It would probably do you well to pick up a book about "What is OOP" or "Understanding OOP" (OOP = Object Oriented Programming) C++ is an object orientated language so in order to do a lot of things that you'll want to do when you create a Windows app, you will need to understand what object oriented programming is all about!
shultas
|
|
|
|
|
I'm wanting to implement PNG file loading in a C++ like Photoshop .8bf plugin development language (FilterMeister). This language has no support for functions, linked-libraries, advanced file manipulation...
I'm trying to find sourcecode for a PNG loader in C/C++ but the best I've found is hazy details on the zlib site. Not being a real coder I need a link to an actual example that I can work from, instead of definitions and technical details.
Thanks for any help,
Shifty Geezer
...
|
|
|
|
|
I'm having trouble linking a CVF subroutine with my VC++ source code. I have the declarations in place and can successfully compile, but when I link, I get the following error -
error LNK2001: unresolved external symbol "void __cdecl LSQFIT(float *,float *,int *,int *)" (?LSQFIT@@$$J0YAXPAM0PAH1@Z)
My source and external subroutine are below -
extern "C" void LSQFIT(float*xp, float*fxp, int*nx, int*maxord);
int main()
{
float fxp[1000],xp[1000];
int maxord[1],nx[1];
*nx = 10;
*maxord = 3;
LSQFIT(xp,fxp,nx,maxord);
....
CVF subroutine -
SUBROUTINE LSQFIT(XP,FXP,NX,MAXORD)
DIMENSION XP(1),FXP(1),COEFF(11),ERR(10)
|
|
|
|
|
While I might be wrong, I'm pretty sure that your main and function declation are in C.
SUBROUTINE LSQFIT(XP,FXP,NX,MAXORD)
DIMENSION XP(1),FXP(1),COEFF(11),ERR(10)
Looks awfully like it is in FORTRAN... While it may be theoretically possible to link the
two, it's very hard at the least. It's bad enough mixing C and C++...
You'd be better looking for a C implementation, or porting the algorithm from Fortan to C.
Iain.
|
|
|
|
|
I am writing an application in MFC. What I am trying to do is see every internet packet that is being recieved or sent through my computer. I am assuming that I am going to need to use Winsock? Other than that, I have no clue, so any help is appreciated.
-Dev578
|
|
|
|
|
|
or check out EtherPeek at http://www.wildpackets.com/[^]
it does cost $$$ but if you are going to do a lot of it, it's completely worth it.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.santacruznetworks.com">Santa Cruz Networks</A>
|
|
|
|
|
I highly recommend Network Programming for Microsoft Windows, Second Edition by Anthony Jones and Jim Ohmund.
Kuphryn
|
|
|
|
|
Check out microsoft's layered service provider sample from platform sdk (used to be in netds\winsock\lsp) and this also could be helpful http://www.microsoft.com/msj/0599/LayeredService/LayeredService.aspx
Edward
|
|
|
|
|
Hello !
I am beginner in C++ and i need some help from you !
I want to make my console program into windows application,
but I dont now how to do it. Please help me !
Thank you.
Boco 
//PROGRAM FOR CALCULATING SUM AND AVERAGE OF TWO NUMBERS
#include
#include
int main ()
{
float num_1, num_2;
double sum, average;
cout << "\n\t\t******************************************* ";
cout << "\n\t\t* PROGRAM FOR CALCULATING SUM AND AVERAGE * ";
cout << "\n\t\t* OF TWO NUMBERS * ";
cout << "\n\t\t* Version 1.0, February, 2004 * ";
cout << "\n\t\t******************************************* ";
cout << "\n\n\n\n\n Enter first number: ";
cin >> num_1;
cout << "\n Enter second number: ";
cin >> num_2;
sum = num_1 + num_2;
average = sum / 2.0;
cout << "\n\n Calculated sum is: " << sum << endl;
cout << "\n Calculated average is: " << average << endl;
cout << "\n\n\n\n\n For exit from program press [Enter] >>>>> ";
getchar();
return (0);
}
|
|
|
|
|
Reposting won't get you an answer any faster.
A Windows application needs to be structured very differently from a console application. You respond to events from the operating system, rather than driving the process yourself. You need, at the very least, to create a window with suitable controls, then start up a message loop. Frameworks such as MFC can provide a lot of the boilerplate code for you.
There isn't space to go into it here, and there are many resources. Try for example Programming Windows by Charles Petzold, Programming Windows with MFC by Jeff Prosise, or for a simpler reference, try Teach Yourself MFC in 24 Hours from SAMS.
I would recommend an MFC dialog-based application, with two edit boxes for the two numbers, static controls for the results, and a Calculate button. You would then perform your calculations and show the results in a BN_CLICKED handler for the button. Alternatively you could simply handle EN_CHANGE on both the edit fields and compute the results as the user types. It's up to you.
|
|
|
|
|
Mike, that sounds very havy, do you have maybe same
example like my program is ?
Boco
|
|
|
|
|
Send me a mail so i can send u the program
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
Hi All,
I want to write an application which should display a pdf file, and some other features like searching,highlight text,zoom etc. Is there any free/paid controls available. I tried using pdf.ocx but it's very slow and also not feature for searching, highlight text etc. Any idea how to do this ?
Thanks
Mahesh Varma.
|
|
|
|
|
We investigating XpdfViewer by Glyph and Cog at http://www.glyphandcog.com
--
Joel Lucsy
|
|
|
|
|
Hello guys,
during debugging the compiler gives this memory leak warning messages. Due to my lack of knowledge, I am not able to find which lines (parts) of the codes causing the memory leak, by telling from the messages.
Detected memory leaks!
Dumping objects ->
{161} normal block at 0x00C86988, 25 bytes long.
Data: <` l > 60 C0 6C 00 08 00 00 00 08 00 00 00 01 00 00 00
{84} normal block at 0x00C867A0, 51 bytes long.
Data: <` l " " > 60 C0 6C 00 22 00 00 00 22 00 00 00 01 00 00 00
{78} normal block at 0x00C86618, 40 bytes long.
Data: <g > 67 00 00 00 D3 01 00 00 00 00 00 00 00 00 00 00
Object dump complete.
Can anyone help?
|
|
|
|
|
The memory leaks are pretty small by size, this suggests that the unfreed objects are some small or tiny variables. Try double-checking your source files that for each memory reserving call (new or malloc) you call the respective deletion call (delete or free).
The final option is to run the debugger, copy each new reserved memory's pointer's target address into paper and then compare these with the posted object addresses. This is tedious and long-term work but allows you to pinpoint what pointers are not freed properly.
Remember that the most common cause for these problems is that you have an object that reserves memory dynamically in it's constructor, but does not free it in the destructor or during it's life cycle. Once again, check your code.
Alternatively, if you have money to spare, try investing into some memory-validation program, which are available through CodeProject partners as well. There are many available, and they don't even cost too much.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Thanks for the help, Antti
I've been looking hard into my code for any suspicious memory reserving calls, so far I have failed to find anything.
Antti Keskinen wrote:
Try double-checking your source files that for each memory reserving call (new or malloc) you call the respective deletion call (delete or free).
I guess my difficulty is that I have not manually made any new or malloc in the program. All the possible memory allocating pointer calls are MFC classes and declared inside the functions of my classes. I'd have to think it should be safe since all of my own classes are deleted before the program's exit. Is there anywhere I should check in particular?
Taking Graham's information,
after define the CRT memory leaks parameter, the message reports one extra memory leak, which seems to be happening within MFC's own code.
Detected memory leaks!
Dumping objects ->
{47} normal block at 0x00C84590, 49 bytes long.
Data: <h l > 68 C0 6C 00 0C 00 00 00 20 00 00 00 01 00 00 00
occmgr.cpp(172) : {46} normal block at 0x00C84530, 32 bytes long.
Data: < > EB 03 00 00 00 00 00 00 E9 03 00 00 00 00 00 00
{45} normal block at 0x00C82E90, 20 bytes long.
Data: < > FF FF FF FF CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
'Prog.exe': Loaded 'C:\WINDOWS\system32\mslbui.dll', No symbols loaded.
'Prog.exe': Loaded 'C:\Program Files\Yahoo!\Messenger\idle.dll', No symbols loaded.
'Prog.exe': Loaded 'C:\WINDOWS\system32\MSIMTF.dll', No symbols loaded.
Detected memory leaks!
Dumping objects ->
{84} normal block at 0x00C86650, 51 bytes long.
Data: <h l " " > 68 C0 6C 00 22 00 00 00 22 00 00 00 01 00 00 00
{161} normal block at 0x00C86898, 25 bytes long.
Data: <h l > 68 C0 6C 00 08 00 00 00 08 00 00 00 01 00 00 00
{78} normal block at 0x00C86548, 40 bytes long.
Data: <g > 67 00 00 00 D3 01 00 00 00 00 00 00 00 00 00 00
Object dump complete.
The program '[1128] Prog.exe: Native' has exited with code 0 (0x0).
I have tried further to use "Setting a Breakpoint on a Memory Allocation Number" technique described in MSDN documentation. I could not seem to get much out it since the debugging would break at some strange points which weren't the specified block number.
For now, I am wondering, according to that extra memory leak detection prior to the original memory leak, can it be assumed that it might not be my code but has something to do with MFC itself?
Worst of all, if I could not determine the sources of the memory leaks, how much performance hit the app would do to the system. I can see about 120 bytes memory leak from the originally posted memory leak, is that all what should be taking account?
Thanks again
|
|
|
|
|
Memory leaks can happen in MFC as well if you use it's routines incorrectly. In these cases, you must check through the MFC Reference in order to determine how a certain class is supposed to be used.
As for the memory blocks, put the definition flag and the include files into your stdafx.h file. This causes them to be included everywhere, and respectively, be effective everywhere. Then call the _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); on your application's InitInstance. This gives you the leak information always when your application exits.
Now place arbitary exit points into your application: during it's startup, after the initializations, during a normal run, at the exit phase and so on. This allows you to determine the position in where to look for the memory leaks.
An additional thing about using MFC: Remember that all it's classes are wrappers or containers for Win32 API routines/objects. This having said, always in your code when you create a bitmap, for example, you can, if you want, call the Delete* methods to safely destroy the underlying Windows object. Sometimes, the destructor of MFC's classes does not call this method, thus leaving the underlying object intact, and leading into a memory leak.
It is difficult to advise you any further without actually seeing the code, but that is unfortunately impossible.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Thanks guys, espcially Antti for the helps,
I had finally found and solved the memory leak problem. I pinpointed it by going back to my each daily souce code backup, find and compare the pair app codes which were before and after the memory leak message was produced. And it turned out to be caused by something which seems rather simple, but I have trouble to understand why.
It's the CStatubar object I've created for my Dialog-based app. It's created within my main class' OnInitDialog()
m_statusbar.Create(this);
m_statusbar.SetIndicators(indicators, 2);
m_statusbar.GetStatusBarCtrl().SetBkColor(RGB(180,180,180));
m_statusbar.SetPaneText(0, "Welcome to m600 Printing Scheduler");
SetTimer(100, 1000, NULL);
the only difference is that previously it was declared as a global variable and placed on the top of the cpp file, and later I moved it into the class declaration scope (h file) so it becomes a class member. The later has caused the memory leak. I do not quite understand why tho. It looks to me that in the later case, the class memebers (including CStatusBar member) would still have been freed upon the exit of the app, when this main class is desctructed?
This would remind me of the obstacle I had previously also about the CStatusBar. Unlike many other classes (such as CEdit), I realised that I could not simply assign a pointer to this class object I created so that to directly access it in other threads. In debug mode, it'd break and in release mode, it'd compile ok and still do what it is supposed to do (say, to change text, pStatusBar->SetPaneText(0, "Testing");. How is this class different?
Thanks alot guys
|
|
|
|
|
I believe that it might be a combination of the status bar and a dialog.
As default, the dialog class is not suited for handling a status bar, so you must override the OnOk handler, and explicitly call 'm_statusbar.DestroyWindow' method to destroy the Windows status bar control upon exit. The dialog class is not aware of the status bar control otherwise than that it is a child control. Upon exit, the class issues a WM_DESTROY for all child controls, but for some reason, the status bar does not handle this properly.
So, call the manual destruction method of the class in the OnOk handler. I think this should remove at least one or two of the memory leaks.
The break problem is because of the multi-threading. Accessing a class directly from across the thread is dangerous, because the memory areas might become corrupted. Instead, add handlers for different messages in your status bar class, and register a set of new Windows messages for your convinience. Messages such as WM_MY_SETTEXT and send the new text string in WPARAM and perhaps the ID in LPARAM. Using Windows messages is a safe way to signal changes across threads.
One last option is to try AFX_MANAGE_STATE( AfxGetStaticModuleState() ); call pair. This function sets the thread/module state until end of it's calling scope. Basically, it ensures that all data within this context's (the thread's) memory block is valid. It works smoothly for DLL's, but I am unsure how it affects multi-threaded applications. It might, or might not, help you. Also, make sure you are linking with the multi-threaded version of the MFC library files. Linking with the single-threaded ones in this case might also be the problem.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Antti Keskinen wrote:
So, call the manual destruction method of the class in the OnOk handler. I think this should remove at least one or two of the memory leaks.
Antti, I further experimented by declaring m_statusbar as a class member and explicitly destroy it upon my overriden OnCancel() call (where all my exit routines go through). Unforunately, to my surprise it did not seem to make any difference. The three memory leaks would still exist, while making m_statusbar as a global variable completely dismisses the memory leaks (at least no longer in the debug window anyway). Can this be explained?
Antti Keskinen wrote:
Accessing a class directly from across the thread is dangerous, because the memory areas might become corrupted. Instead, add handlers for different messages in your status bar class, and register a set of new Windows messages for your convinience.
Yes, SendMessage() is what I've learnt to use later and I found is quite efficient and reliable. However, I am just wondering for those object pointers I previously created for directly class access and have worked successfully within multiple threads, can I be safe to leave them as they are, without having to worry about memory corrupton? Or the corruption is still possible as more objects are being made later.
Thank you again, Antti
Johnny
|
|
|
|
|
I feel like a walking advertisement, but there's some commercial product outs there that's great for this:
(1) Check out BoundsChecker, it will tell you exactly what code created the memory you wish to free. (http://www.compuware.com/products/devpartner/bounds.htm[^])
(2) SmartHeap -- an alternate memory manager. Detects all kinds of bad memory problems, and also tell you exactly who allocated the memory and it's faster than the VC++ mem manager. (microquill.com)
Neither of these are cheap. But if you figure your time spent chasing memory leaks, they pay for themselves quickly.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.santacruznetworks.com">Santa Cruz Networks</A>
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
