|
Hi everyone. I am VERY new at programming and I am wondering if someone to show me step by step how to do something that I know is incredibly easy. I want to be able to run a program that I write without having to go into the actual workspace and compile and execute it. I would like to know how to just be able to click on an icon or something and have the program pop up w/o using my developer studio. Could someone help please? By the way, I use Microsoft Visual C++ 4.0 so please keep that in mind when replying. Thanks in advance!
|
|
|
|
|
HackerBoy wrote:
I want to be able to run a program that I write without having to go into the actual workspace and compile and execute it.
what you need is a slave.
(no offense  )
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Maybe I posed my question the wrong way. What I meant was is it possible and how do you turn a program into a graphics icon or other representation of the program that you can click on and run that cuts out the use of the compiler.
|
|
|
|
|
Once you have compiled your project you can use your .exe-file by clicking on the icon in explorer or anywhere else. the icon itself can be changed using the resource editor inside of VC or programs like ResHacker.
modified 12-Sep-18 21:01pm.
|
|
|
|
|
I'm sorry, but I really don't understand this. Could you break it down for me? I'm sorry if I am being annoying, I am just incredibly new at this.
|
|
|
|
|
It's not perfectly clear what you're asking, but I'll take a crack at it. You can't run a program without compiling it. When you build a program in Visual Studio you enter text elements that the compiler understands. When you Build your program the IDE first compiles the files in your program, then links them together into a binary file that can be directly executed by the computer. Normally you'll add to the code, change things, and rebuild it within the IDE many times until you're satisfied with the result and call it done. After the last build, whatever it is that you built will exist as an executable file with the same name as your project, and the file extension .exe. This program can be moved, copied, and run just like any other program on your computer - it doesn't go away just because you shut down Visual Studio.
"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.
|
|
|
|
|
Where would the executable file exist? How would I find it? When I do find it, say I move it to become a desktop icon, would it still work?
|
|
|
|
|
I don't recall where VC4 stores them - I think it's in the Project file, but you can always use the Search function in Windows to locate it. Once you do, make note of it, as that's where VC4 will put future files.
HackerBoy wrote:
say I move it to become a desktop icon, would it still work?
That's a definite yes or no. It depends. Simple console programs often run standalone, others have to be installed in Windows. If the program has no external dependencies (dlls, resource files, etc) it should run fine from anywhere. More complex programs usually have to install other files they depend on to run on the target machine, and if you use any custom dlls in your program, these have to be registered with the operating system.
Spend some time with Mike Dunn's excellent C++ FAQs[^] article and review the many good Beginner articles on this site. I'd also recommend picking up a book or two on Windows programming in general, and programming with VC++ in particular. Most of what you'll find now are books on .Net - skip them. Look for books on VC++6 and earlier, as most of what you're trying to learn will be found there. I find them in cheap discontinued book piles in bookstores; it's nice to find a $80 text for $5 that's current enough for my needs.
"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.
|
|
|
|
|
Thank you for answerng my questions even though they were juvenile. And especially thanks for the references to learning materials. 
|
|
|
|
|
HackerBoy wrote:
even though they were juvenile
Not at all. We all start from the beginning, and we're all beginners at something. I've been programming for 25 years, yet I'm a beginner at C++ and Windows in general. That's what this site is for, swapping knowledge among us, each with his own unique skillset.
"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.
|
|
|
|
|
Another possibly useful reference - there are a few (slightly out of date) Visual C++ books that can be downloaded from http://www.xatrix.org/index-fbooks.html . I don't know how good these particular ones are, but most VC++ books have resonable beginner tutorials.
|
|
|
|
|
|
I have a program that I am compiling in Visual C++ .NET (Ver. 7.0.9466) that generates tons of C4251, C4275 and C4661 warnings. I know why they are being generated and wish to ignore them. I would like to not have them generated at all, because there are so many that it slows my compile down to half speed. There is the C/C++ Advanced option for a project to "Disable Specific Warnings". I thought this would be exactly what I needed, but when I added them into the field "4251;4275;4661", they were still generated. The only I was able to get them to not generate was to also set the "Warning Level" (found under the C/C++ General option) to 1. I would describe this behavior as a bug.
Has anyone else seen this same behavior? Is there a fix or workaround for it? Thanks in advance for any response.
|
|
|
|
|
Is "4251;4275;4661" the right syntax for that setting? Check the help, it might be comma- or space-separated instead.
If that still doesn't work, add a pragma to stdafx.h before your includes:
#pragma warning(disable:4251 4275 4661)
and don't forget to eventually fix the code that's creating the warnings
--Mike--
Ericahist | CP SearchBar v2.0.2 | Homepage | 1ClickPicGrabber New v2.0! | RightClick-Encrypt
You cannot stop me with paramecium alone!
|
|
|
|
|
First, the warnings are :
C4251 : 'identifier' : class 'type' needs to have dll-interface to be used by clients of class 'type2'
C4275 : non ? DLL-interface classkey 'identifier' used as base for DLL-interface classkey 'identifier'
C4661 : 'identifier' : no suitable definition provided for explicit template instantiation request
For 4251 and 4275,
From MSDN
"Inheritance and Exportable Classes
All base classes of an exportable class must be exportable. If not, a compiler warning is generated. Moreover, all accessible members that are also classes must be exportable. This rule permits a dllexport class to inherit from a dllimport class, and a dllimport class to inherit from a dllexport class (though the latter is not recommended). As a rule, everything that is accessible to the DLL's client (according to C++ access rules) should be part of the exportable interface. This includes private data members referenced in inline functions."
I read this as,
For 4251 :
If your variable is protected or private than you can ignore 4251.
For 4275 :
You have to fix this. I am not sure whether protected or private inheritance is an exception.
For 4661 :
You will get an unresolved external symbol if you try to use 'identifier', since the compiler could not find the function body of your templated function, and did not generate the code for that function, although you explicitly requested it. Please look at the MSDN for C4661, if you have not done already.
|
|
|
|
|
Hi,
I've created a DLL in VC++ 6. The DLL works fine in Win95/98, NT4, 2000 but not in XP. XP for some reason gives "Access violation at address ........ in module <dll>." errors.
The first time I was getting this message, I was linking with mmsystem.lib (for the timeGetTime function). I checked out the DLL using Dependency Walker (depends.exe). On Win2k it pulled up just fine. Under XP, it said "Warning: at least one module has an unresolved import due to a missing export function in a delay-load dependent module." Under MPR.DLL, it appeared to be missing the WNetRestoreConnectionA function (I'm not even using this function in my DLL -- only the timeGetTime function). I checked the mpr.dll version on my win2k machine (the one that I'm coding on) versus the version on the XP Pro test machine. They were different (duh -- different versions of Windows).
I resolved this problem by using the LoadLibrary and GetProcAddress functions with the WINMM.DLL. When I tried to run the program calling the DLL on the XP machine, I got the error "Access violation at address 77C3F081 in module 'MSVCRT.DLL'. Read of address 00000000."
I'm using the <string> functions (sprintf, strncmp, etc.). I included the msvcrt.lib library, but decided to try building the DLL with the libc.lib library. Finally, I got the error message "Access violation at address 100026C8 in module 'CPUID.DLL'. Read of address 00000000." The DLL "CPUID.DLL" is the DLL that I'm building.
From my limited knowledge, I believe that the "Read of address 00000000" message means that the function didn't get loaded at all.
What can I do to fix this? This is the first time I've run into this problem (working on all versions except one -- XP).
Thank you in advanced for your help,
Tim Clegg
|
|
|
|
|
TClegg wrote:
From my limited knowledge, I believe that the "Read of address 00000000" message means that the function didn't get loaded at all.
It sounds like a NULL pointer was dereferenced for read access. And if it happened in your DLL, it's your bug.
--
Watcha' gonna do, when Hulkamania runs wild on you!?
|
|
|
|
|
Do you have any ideas as to why it's happening just on Windows XP? If it happened on all of the other versions, I'd be looking at my code, but since it's just on XP (I test it on 2000 and it works fine -- the same build) that I'm getting these issues. I'm wondering if it's some project setting in VC++6 that could be causing this? The only other option that I can think of is to get the latest win32 SDK and try compiling with that. The only problem with my last hypothesis is that there's always at minimum basic backwards-compatibility between old and new versions of DLLs (at least usually).
|
|
|
|
|
It may very well be a problem with different versions of DLLs found in the system. XP probably delivers newer DLLs (MSVCRT et al) than Windows 2000, and if the semantics have changed (bug fixes, etc), then your code may very well be affected.
Can't you just debug the app on XP to see what's going on?
--
Watcha' gonna do, when Hulkamania runs wild on you!?
|
|
|
|
|
Hi All,
I am very much in need of a program, which I have downloaded a year back. I presume, I downloaded it from Codeproject / MSDN Sample. This program when executed, launches a VB like IDE( Editor ), having toolbox and property windows, from where you can drag and drop controls to a form provided, and we can even write code by double clicking on the controls. I forgot the name of the application, which is supplied with the source.
If any one has seen or downloaded the same, pl. help me by giving the link / the name of the program.
Thanks
Jugs
"A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
|
|
|
|
|
Sounds alot like VBLite[^],
the ATL control containment example by Dharma Shukla and Chris Sells.
And if the paths that I have followed/have tread against the flow/there is no need for sorrow
I am coming home
Return, Crüxshadows
|
|
|
|
|
Thank you very much stephan. This is exactly what I was looking for....
Once again a big Thanks, and a Happy New year....
Jugs
"A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
|
|
|
|
|
Hello. I've created a standard MFC app using VC++ 2002.
The toolbar works great and uses CMainFrame::OnDatabase and ::OnTransport to fire-up a child window specific to the button's stated purpose. So far, I have two buttons, one to fire-up the "database functions" window and then one for the "transport functions" window.
BUT, I need to ensure that only ONE child window that does the specific purpose is created when the button is pressed. It doesn't make sense to allow the user to hit a button multiple times, creating multiple "database" or "transport" function child windows... I want to disable a specific button when the child window is visible.
So, I've been trying to work with the ON_UPDATE_COMMAND_UI messages to disable the toolbar button when the child window is successfully created from CMainFrame and then re-enable the toolbar button when the child window is closed by catching the WM_CLOSE message in CMainFrame.
I've experimented with various codings, trying to do the toolbar notifications in both CMainFrame and then, in the two child window objects I have created so far. No real success yet.
Could someone provide me with some source code showing an example of what I need to accomplish?? There's gotta be an accepted way to accomplish this.
Thanks!
Joe
|
|
|
|
|
The ON_UPDATE_COMMAND_UI should be called on OnIdle ( IIRC ), so will be called when stuff changes in the UI.
In the ON_UPDATE_COMMAND_UI callback, you can do something like :
...
pCmdUI->Enable( ( IsYourChildWindowVisible() == TRUE ) );
...
Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )
|
|
|
|
|
That is working A-OK but...
If both child windows are visible, and one loses the focus, the toolbar button of the lost-focus window re-enables itself. In other words, "visible" doesn't actually mean visible but rather "has input focus."
Is there a function to use other than IsWindowVisible that will detect windows that are visible but perhaps don't have the input focus?
Thanks again. Getting there.
Joe
Code in each window's .h/.cpp respective files is (only one shown below):
(in .h file)
afx_msg void OnUpdateToolbarButtons(CCmdUI* pCmdUI);
(in .cpp file)
ON_UPDATE_COMMAND_UI (ID_TRANSPORT, OnUpdateToolbarButtons)
void CHelloWnd::OnUpdateToolbarButtons (CCmdUI* pCmdUI) {
if (IsWindowVisible() == TRUE) {
pCmdUI->Enable (FALSE);
}
if (IsWindowVisible() == FALSE) {
pCmdUI->Enable (TRUE);
}
}
Other file works with the CDatabaseWnd object and addresses that toolbar button message ID and object.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
