|
you could try do a search hereabouts for 'versioninfo' or 'version info' - several authors have published articles about reading this from the resource buried in an exe. I dont know if it covers file size though, the obvious way of handling that is to get the exe name using a system call, then use one of the shell utilities or similar eg directory search to return the file size
hope this starts you on the right foot
'G'
|
|
|
|
|
GetModuleFileName(...) will return the location where MyApp.exe was launched.
CFile::GetStatus(...) will return file size, time stamp, ...
TCHAR chFileName[_MAX_PATH]="";
GetModuleFileName(NULL, chFileName, sizeof(chFileName));
CFileStatus rStatus;
CFile::GetStatus(chFileName, rStatus);
|
|
|
|
|
thanks for helping out .. on re-reading his question, he probably doesnt need 'version info' - and I'm flat maggot this am at the office and couldnt remember GerModuleFileName - I'd have had to do a search myself to find it ..
'G'
|
|
|
|
|
Thanks All! These are excellent replies and just what I'm looking for.
|
|
|
|
|
I have an application that I can build, then run in Debug mode. In that mode it is fine. When I configure the project for release, re-build, then try to run the application. I get exceptions. Has anyone ever seen this happen before?? I think I may need to add exception handling code in all my functions to find the problem.
Jerry
|
|
|
|
|
There are quite few differences between the different builds. Your description is too vague to give any specific insight, however hope this helps, in particular rule 4:
http://www.codeproject.com/debug/releasemode.asp[^]
Marcus Spitzmiller
"Why must life be so hard? Why must I fail at every attempt at masonry?" - Homer
|
|
|
|
|
I get a message that an exception occurred in the exe. I get a message box that lets me attempt to find the problem...but when I try stepping into the application to find the problem, I get assembler code...so I dont know where the problem is.
Thanks.
Jerry
|
|
|
|
|
Hi Jerry - If you get the assembler code, you can always then look at the call stack to see in which function the execution has stopped. You can show the call stack in the Visual Studio .NET IDE by Debug->Windows->Call Stack.
Hope this helps...
Marcus Spitzmiller
"Why must life be so hard? Why must I fail at every attempt at masonry?" - Homer
|
|
|
|
|
Here is another useful article.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Hi All,
Using some of the samples provided here and at CodeGuru I have mannaged to create a Split View with a Form (with a comboBox) and a Document View for the second pane. Now I need to gain access to the Document so it can be printed etc. The View for the Document is based on the CScrollView. What I need is to have the Document gain the focus and have the Menu change to the IDR_MYDOCTYPE. Can anyone shed some much needed light on this subject. Here is how I am creating the Split:
BOOL CECalSplitter::OnCreateClient(LPCREATESTRUCT /*lpcs*/,
CCreateContext* pContext)
{
if (!m_wndSplitter.CreateStatic(this, 1, 2))
{
TRACE0("Failed to CreateStaticSplitter\n");
return FALSE;
}
// add the first splitter pane - the default view in column 1
if (!m_wndSplitter.CreateView(0, 1,
pContext->m_pNewViewClass, CSize(0,0),pContext))
{
TRACE0("Failed to create first pane\n");
return FALSE;
}
// add the second splitter pane - an input view in column 0
if (!m_wndSplitter.CreateView(0,0,
RUNTIME_CLASS(CFrmView), CSize(425,50),pContext))
{
TRACE0("Failed to create second pane\n");
return FALSE;
}
// activate the input view
SetActiveView((CView*)m_wndSplitter.GetPane(0,1));
return TRUE;
}
When the ComboBox is closed (All Items have been selected) the Document is then displayed. I.E. I am creating the document based on items selected which I am placing in specific points in the document.
Any help would be appreciated.
Thanks, Charlie
|
|
|
|
|
I have a small piece of code that was used in the book that I have and the author does not do a good job explaining what it means. Could someone explain this to me? I have an idea but I am trying to get a better understand....thanks!
CClientDC dc(this);
OnPrepareDC(&dc);
dc.DPtoLP (&point);
Then he uses it in these two functions:
void CEx14fView::OnLButtonDown(UINT nFlags, CPoint point)
{
CClientDC dc(this);
OnPrepareDC(&dc);
dc.DPtoLP (&point);
Pt1 = point;
}
void CEx14fView::OnLButtonUp(UINT nFlags, CPoint point)
{
CEx14fDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
CClientDC dc(this);
OnPrepareDC(&dc);
dc.DPtoLP (&point);
Pt2 = point;
pDoc->AddLine (Pt1, Pt2);
Invalidate();
}
There are 10 kinds of people in this world. Those who understand binary and those who don't.
|
|
|
|
|
BrockVnm wrote:
CClientDC dc(this);
This creates a device context out of the current window. A DC is what you draw on.
Your app is obviously Doc/View, because OnPrepareDC is a function in the CView class. It's generally called by the framework before the OnPaint method.
DPToLP converts an array of points from co-ordinates in device units, into co-ordinates in logical units.
The net result is that this guy is an idiot. He's grabbing the device context and mangling with it in order to work out the point that the mouse is over, relative to the window instead of the screen. The CWnd class has methods to do this directly ( ScreenToClient and ClientToScreen, from memory ).
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
Christian Graus wrote:
The net result is that this guy is an idiot. He's grabbing the device context and mangling with it in order to work out the point that the mouse is over, relative to the window instead of the screen. The CWnd class has methods to do this directly ( ScreenToClient and ClientToScreen, from memory ).
Not really. This guy's code converts from device coordinates to logical coordinates (the point passed to the function is already relative to the window's client area). ScreenToClient() and ClientToScreen() convert to and from screen- and window-relative device coordinates and have no knowledge of the current mapping mode.
Ryan "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 am doing a project involving to get text from the msm coversation window
can any one help me
|
|
|
|
|
|
Hello,
I've been trying to write a program in C++ (using Borland C++ 5.02 compiler, alternating with MSVC++ 6.0) that communicates with the serial port to read in data.
I used the book "Serial Communications in C and C++" by Mark Goodwin as a reference, as it came with a floppy that contained source files including a class that reduced serial communications to a matter of declaring a variable and calling some member functions on it (eg. Port1.in_ready(), Port1.get(), etc).
Anyway, the code compiles, but it fails in the linking stage as it says that there are external errors dealing with the class's commands -- even the example code would not work.
So I did a bit of research and found out that XP does not allow users to freely access the serial COM ports (1-4), among others. One site suggested that downloading a certain driver would fix things, but I have not been able to find anything of that nature. Does anyone have any experience dealing with a problem similar to this? Is there something out there that I haven't found yet?
Any help is greatly appreciated...
|
|
|
|
|
XP does not prevent access to the serial ports. But you can not use a Win98-compilant code to operate the serial ports. The access methods are different, and a code that compiles, links and runs fine on a Win98/Me-platform no longer does that under XP.
Under XP, direct access (assembly-based) to the serial ports is prohibited: instead, you must utilize the Platform SDK commands to operate the ports. Luckily, Windows-family treats ports as files, so using CreateFile with a filename "COM1" opens the port.
Here's a link to the MSDN Platform SDK site that discusses communications. The link.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Thanks for the reply.
So I have to basically rewrite a portion of my code to comply with using CreateFile and whatnot. This is where it gets confusing for me.
From the link you provided:
----
/* A sample program to illustrate setting up a serial port. */
#include <windows.h>
int main(int argc, char *argv[])
{
DCB dcb;
HANDLE hCom;
BOOL fSuccess;
char *pcCommPort = "COM2";
hCom = CreateFile( pcCommPort,
GENERIC_READ | GENERIC_WRITE,
0, // must be opened with exclusive-access
NULL, // no security attributes
OPEN_EXISTING, // must use OPEN_EXISTING
0, // not overlapped I/O
NULL // hTemplate must be NULL for comm devices
);
if (hCom == INVALID_HANDLE_VALUE)
{
// Handle the error.
printf ("CreateFile failed with error %d.\n", GetLastError());
return (1);
}
// Build on the current configuration, and skip setting the size
// of the input and output buffers with SetupComm.
fSuccess = GetCommState(hCom, &dcb);
if (!fSuccess)
{
// Handle the error.
printf ("GetCommState failed with error %d.\n", GetLastError());
return (2);
}
// Fill in DCB: 57,600 bps, 8 data bits, no parity, and 1 stop bit.
dcb.BaudRate = CBR_57600; // set the baud rate
dcb.ByteSize = 8; // data size, xmit, and rcv
dcb.Parity = NOPARITY; // no parity bit
dcb.StopBits = ONESTOPBIT; // one stop bit
fSuccess = SetCommState(hCom, &dcb);
if (!fSuccess)
{
// Handle the error.
printf ("SetCommState failed with error %d.\n", GetLastError());
return (3);
}
printf ("Serial port %s successfully reconfigured.\n", pcCommPort);
return (0);
}
-----
This sample program confuses me a great deal. Why does the main program need parameters (I was under the impression that it was called by the OS and executing began there -- thus, there are no inputs... and to further complicate things, neither of those parameters are used in the program!). Also, what are these data types that are declared - DCB, HANDLE, and BOOL (capital bool? C++ is case-sensitive, no?)?
I guess I'm just overall sketchy on how to use CreateFile and those data types (HANDLE seems to be the port's data type, I guess), since I thought using a class that already did these things was the way to go and so didn't take the time to familiarize myself with them. Could you clarify some of these questions for me? I really appreciate the help.
Thank you.
|
|
|
|
|
The sample program is written for a console application. Thus, the main function takes two parameters. The first one is a count of arguments, and is always equal or greater to 1. Having 1 there means that there are no actual arguments. The second is a pointer to a character string that specifies these arguments.
These parameters are filled in by the OS when you execute this program. There is no need for you to use them, if you don't want to, but they offer a change for run-time control of the program. The parameter variables are not used: the program, although it offers the use of parameters, doesn't support them. They do nothing, so to speak.
The data types DCB, HANDLE and BOOL are Windows Data Types. They are (mostly) defined in Windows.h, but you can find explanations from MSDN Library as well. DCB is a structure that depicts the format of a serial port. You fill this structure with relevant data (it has members for that), and send it to a serial port. Thus, the serial port gets configured to match your needs. You can set things like baud rate, parity bit, stop bit etc through this structure.
HANDLE, on the other hand, represents the HAL (Hardware Abstraction Layer) -provided symbol of the data or a device requested. In english, everything in Windows is handles. You have a handle to a file, a handle to a brush or pen, a handle to a window (critical) and a handle to a program instance. You can consider it as a "tree of classes". HANDLE is the parent class, representing a handle of an object. HINSTANCE is a derived one, representing a specialized handle, a handle to a program instance. In real, none of these are actual classes. But thinking them like such makes things a bit easier to understand. Because there are no "a handle to a port", the general HANDLE is used instead.
BOOL represents a boolean value in Windows: < 1 = false, > 1 = true. It exists because old Windows programming platform (3.1 or something) didn't have support for the actual C++ 'boolean' value, bool. This variable (BOOL) is made to emulate a boolean value in Windows environment. But basically, this and the C++ boolean are one and a same thing nowadays. The variable is provided for backward-compatibility.
All these questions (and many more) about Windows-programming are answered in Charles Peltzoid's excellent book 'Programming Windows'. It is _the_ bible of every Windows-developer. I suggest you to grab it from a local bookstore or a library and read it through. It will clarify many issues to you, giving exact knowledge of what the handles really are, how they work, and how to use them.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
hey keep looking here at codeproject
it isn't easy to do it in xp
but solutions are here
don't forget CCriticalSection !
|
|
|
|
|
Check out MSDN.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfiles/html/msdn_serial.asp
Kuphryn
|
|
|
|
|
Hi,
In a multithreaded C++ application, how to find out the % of CPU used by some of the threads from within the program
|
|
|
|
|
See if my response here will get you started.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Thanks for your response. Can you tell me how to find out the memory footprint for the processes from the program?
|
|
|
|
|
ben2 wrote:
Can you tell me how to find out the memory footprint for the processes from the program?
Do you mean the heap or the stack? If the former, see this article. If the latter, then I'm not sure.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
