|
|
Actually I don't to make the dialog part of the taskbar, just the ability to "stick" it to the desktop side and extend it to ocupy that side of the desktop.
|
|
|
|
|
See WM_MOVING - write a handler for this message to force the window to any location on the desktop.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Hello,
I have been looking at a 2D ActiveX Control that was posted some time ago as part of this forum. Link should be below. I want to have a good understand of just how the code for the control operates. Can anyone give me a brief overview of how code works, etc? Apparently all the code is downloadable...so maybe I can step through some of the code in debug mode.
http://www.codeproject.com/miscctrl/ntgraph_activex.asp
Thanks.
Jerry
|
|
|
|
|
Why don't you ask on the forum of the article itself ?? The author of the article will surely know much better how its control works than us.
|
|
|
|
|
Hallo guys,
i have a library file (done for c) which works perfectly with vc++ console application. but when i do the same thing with mfc project it doesnt work. I there any thing to do for piping or please help me in this regard-
thank you guys in advance
kingsly
|
|
|
|
|
I can't help you if you don't describe what exactly the problem is. Is it compiling, c++ runtime errors, exceptions, or whatever?
Don't try it, just do it! 
|
|
|
|
|
Alexander is correct!
Basicaly, C/C++ standard I/O is designed for console programs (the least common denometer).
Piping? No, piping just makes the output an argument to another program (there is no interaction, just display of results).
1) Is it a text only console application?
In that case it is not diffacult, provided you have the library code. What I am reffering to is the parts that provide input/output, the rest does not matter.
For instance, replace all the printf() functions with sprintf() to store the output in at C-String then use a windows text output functions to display it in a window (there is no window output function equivalent to printf()). If it just takes some input on the command line (normaly) and outputs it to the screen, then no problem (an edit control will work).
If it requires interaction from the user (input),
I would consider popping up a dialogbox to ask for the additional input (that way you can still output the text to the same edit control).
2) If it has its' own windowing interface, well you'll just have to figure out how to rewrite the interface under windows (or MFC).
3) If you don't have the source code and you have no control over the I/O, then you are in deep sh** and can do nothing but rewite the libraray.
Good Luck!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
First of all, thanks a lot for both of u. Its GPIB card communication to an amplifier to set the values for it and recieve the values also. with GPIB , i hav e c library through i communicate.. it has lik iprintf,iscanf for setting the values and normal printf for displaying the output in the console window... it works ... but i put the same commands like iprintf, iscanf in a button event and retrive in edit box it doesnt work...
So please help me in this regard..
|
|
|
|
|
Oh man! If the C-library is designed to talk to the hardware directly, you may have a major problem! What I mean is that any modern system, based on NT or above (NT/Win2000/XP), will probably refuse to allow you direct access to the hardware (for security reasons). That means, you need a hardware driver (or to create one).
Google: "name of your library", iprintf, iscanf.
Maybe you will find something useful.
I Reccomend searching to a new GBIB library.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
I'm using Visual Studio .Net to create C++ and ATL dll projects. We have a LARGE dll library, and I do not want to set the resource dll version info for each one.
Does anyone know of a way to override the dll version info that's compiled into the DLLs resources? I would like each DLL to return a common set of information (company name, copyright, etc.). Is there an override or callback that I can use to set that information at runtime?
Thanks,
Aaron Stibich
Innovative Technologies Inc.
|
|
|
|
|
There is... you have to write to the resource section of the dll file... search google, I'm sure you will find many examples of how to do this.
Don't try it, just do it!
|
|
|
|
|
The version information is embedded within the resources in a version information block.
You can build your modules with a common set of includes so that they all have the same information and therefore at runtime would present the same information to any tool querying the version information block. There is not an API to 'get version information' that is called within your modules, so there is nothing you can readily override at runtime.
|
|
|
|
|
Blake Miller wrote:
There is not an API to 'get version information' that is called within your modules, so there is nothing you can readily override at runtime.
Maybe I'm not understanding your reply, but isn't that what VerQueryValue(), GetFileVersionInfo(), and UpdateResource() are for?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Could be 
I REALLY believe he wanted to know if there was an API he could intercept or hijack so that when it was called from OUTSIDE his modules, he could return version information that was consistent. At least, that is how I interpeted the original question. Or, put yet another way, 'what function do I export that clients call to get my version information' and the answer to that is "there is not one that is standardized".
Therefore, he should build all his modules with consistent version information, and the easiest way to do that is to make them all include a common file with similar version information. If that is too much trouble, then, yes, a tool that plugs a version information resource into an already built module would suffice. Extra work and effort, but certainly doable.
|
|
|
|
|
This is a total newbie question, and am almost too embarased to ask it, but bear with me...
I created a program in VS.Net 2003 with windows forms, buttons, menus, etc... How to I run this program on other machines without VS.Net or any framework installed? I copied the .exe file from the debug folder, but it won't run on other machines
Any help would be appreciated (and a little newbie bashing will be tolerated)
|
|
|
|
|
Ooder wrote:
How to I run this program on other machines without VS.Net or any framework installed?
You can't. The .Net framework is required on the target machine.
Ooder wrote:
I copied the .exe file from the debug folder, but it won't run on other machines
You must compile the program in Release mode and copy that version to the target machine.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
So any program I create won't work on another computer unless it has the .Net framework installed, even if I compile it in Release mode?
|
|
|
|
|
Yes that is the advantage of .NET - redistributable of 20 MB or so... 
Of course, maybe it will be deployed already with future (maybe XP already has it...) operating systems.
|
|
|
|
|
There are tools out there that allow you to merge the framework with your exe and compile the MSIL to native code...
Strongly not recommended because your exe will not be serviceable (and a raft of other disadvantages). Just install the framework on the machine. period
Alex Korchemniy
|
|
|
|
|
I have not used VS.NET, but it should allow you to staticaly link to the libraries you are using. what that means is that the library becomes part of your program. In the passed that used to mean the entire library, but today it just means the parts that you actualy use. This will make you program much larger, depending on how much of it is linked to your program.
The main advatage of using DLLs, is that you may be sharing the library with other programs. If the creator of the DLL fixes minor errors in the DLL and the user update that same DLL, then the fixes also affect your program.
The disadvatage of using DLLs, is that you must redistibute the DLLs with your program (just incase your users do not have it installed).
As for DEBUG and RELEASE: The problem is exactly the same thing, you have to ether staticaly link the DLL libraries or install the libraries on the target machine. The only reason for installing a DEBUG version on a target machine is that it will give you some feed-back. You can accomplish that in the DEBUG or RELEASE version by setting your own a define statement, instead of using the _DEBUG statement. The advatage of useing the _DEBUG statement is that it will generate the ASSERT dialogbox on the the target machine. The disavantage is that MFC will (some-times) generate an invalid ASSERT dialogbox, meaning that the call will fail but do no damage (if youre handling the result, then no problem).
Sorry, I tend to get carried away.
Good Luck!.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
How do I make the window for my program non-resizable?
|
|
|
|
|
One way is to remove the WS_THICKFRAME style.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
And how exactly would I do that?
|
|
|
|
|
By reading here.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
