|
// Hassancap.cpp : Defines the entry point for the application.
//
#include "stdafx.h"
#include "Hassancap.h"
#define MAX_LOADSTRING 100
// Global Variables:
HINSTANCE hInst; // current instance
TCHAR szTitle[MAX_LOADSTRING]; // The title bar text
TCHAR szWindowClass[MAX_LOADSTRING]; // the main window class name
// Forward declarations of functions included in this code module:
ATOM MyRegisterClass(HINSTANCE hInstance);
BOOL InitInstance(HINSTANCE, int);
LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);
INT_PTR CALLBACK About(HWND, UINT, WPARAM, LPARAM);
int APIENTRY _tWinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
UNREFERENCED_PARAMETER(hPrevInstance);
UNREFERENCED_PARAMETER(lpCmdLine);
// TODO: Place code here.
MSG msg;
HACCEL hAccelTable;
// Initialize global strings
LoadString(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);
LoadString(hInstance, IDC_HASSANCAP, szWindowClass, MAX_LOADSTRING);
MyRegisterClass(hInstance);
// Perform application initialization:
if (!InitInstance (hInstance, nCmdShow))
{
return FALSE;
}
hAccelTable = LoadAccelerators(hInstance, MAKEINTRESOURCE(IDC_HASSANCAP));
// Main message loop:
while (GetMessage(&msg, NULL, 0, 0))
{
if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
return (int) msg.wParam;
}
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
// COMMENTS:
//
// This function and its usage are only necessary if you want this code
// to be compatible with Win32 systems prior to the 'RegisterClassEx'
// function that was added to Windows 95. It is important to call this function
// so that the application will get 'well formed' small icons associated
// with it.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEX wcex;
wcex.cbSize = sizeof(WNDCLASSEX);
wcex.style = CS_HREDRAW | CS_VREDRAW;
wcex.lpfnWndProc = WndProc;
wcex.cbClsExtra = 0;
wcex.cbWndExtra = 0;
wcex.hInstance = hInstance;
wcex.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_HASSANCAP));
wcex.hCursor = LoadCursor(NULL, IDC_ARROW);
wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
wcex.lpszMenuName = MAKEINTRESOURCE(IDC_HASSANCAP);
wcex.lpszClassName = szWindowClass;
wcex.hIconSm = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));
return RegisterClassEx(&wcex);
}
//
//
BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
{
HWND hWnd;
hInst = hInstance; // Store instance handle in our global variable
hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);
// hWnd = CreateWindow(szWindowClass, szTitle, WS_POPUPWINDOW|WS_CAPTION|WS_VISIBLE,
//480, 400, 320, 240, NULL, NULL, hInstance, NULL);
if (!hWnd)
{
return FALSE;
}
ShowWindow(hWnd, nCmdShow);
UpdateWindow(hWnd);
return TRUE;
}
//
// FUNCTION: WndProc(HWND, UINT, WPARAM, LPARAM)
//
// PURPOSE: Processes messages for the main window.
//
// WM_COMMAND - process the application menu
// WM_PAINT - Paint the main window
// WM_DESTROY - post a quit message and return
//
//
LRESULT CALLBACK WndProc (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
HDC hdc ;
PAINTSTRUCT ps ;
RECT rect ;
HDC hdcWindow;
static int nScreenWidth, nScreenHeight;
switch (message)
{
case WM_CREATE:
nScreenWidth = GetSystemMetrics(SM_CXSCREEN);
nScreenHeight = GetSystemMetrics(SM_CYSCREEN);
SetTimer( hwnd,0,2000,NULL);
return 0 ;
case WM_LBUTTONDOWN:
{
HWND tBarHandle= NULL;
return 0;
}
case WM_PAINT:
{
hdc = BeginPaint (hwnd, &ps) ;
hdcWindow = GetWindowDC( hwnd);
HWND hDesktopWnd = GetDesktopWindow();
HDC Source = GetDC(hDesktopWnd);
HDC Destination = CreateCompatibleDC(Source);
HBITMAP hCaptureBitmap =CreateCompatibleBitmap(Source, nScreenWidth, nScreenHeight);
SelectObject(Destination,hCaptureBitmap);
BitBlt(Destination,0,0,nScreenWidth,nScreenHeight, Source, 0, 0, SRCCOPY);
BitBlt(hdc,0,0 , nScreenWidth, nScreenHeight, Source, 0,0, SRCCOPY);
ReleaseDC(hDesktopWnd,Destination);
DeleteDC(Source);
DeleteObject(hCaptureBitmap);
EndPaint (hwnd, &ps) ;
}
return 0 ;
case WM_TIMER:
GetClientRect(hwnd,&rect);
InvalidateRect( hwnd, &rect, true);
return 0;
case WM_DESTROY:
PostQuitMessage (0) ;
return 0 ;
}
return DefWindowProc (hwnd, message, wParam, lParam) ;
}
How to convert DDB format to DIB format using GETDIBits() function ...
|
|
|
|
|
and you think that by posting a huge piece of code (not even formatted correctly), with a title that is far from being representative of you problem, by spamming the board (yeah, asking a question more than once is quite always bad seen) and with a question summed up in on of the smallest lines that can be people will help you ? seriously
you'd better start reading this[^] and this[^] first...
|
|
|
|
|
|
HassanKU wrote: sorry 4 dat...
oh my god
and please please, speak english !!!
|
|
|
|
|
And one thing that you forgot to tell when post a code use of Pre tags.;)
|
|
|
|
|
i didn't forget, i said "posting a huge piece of code (not even formatted correctly)" and linked to the posting guidelines... which implied it
|
|
|
|
|
Yeah I see your answer "and you think that by posting a huge piece of code (not even formatted correctly),"
|
|
|
|
|
toxcct wrote: seriously
Same here,
|
|
|
|
|
toxcct wrote: with a question summed up in on of the smallest lines that can be people will help you ? seriously
he he he
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
google
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Hi,
I need to write a large amount of data continuosly to the harddrive at a max rate of 5 ms. Is this possible just to take data from memory and constantly write it to hard drive without making it lose any data. Or do I have to do something fancy to ensure this? This data will be continuously coming in for like a few hours.
Thanks in advance.
|
|
|
|
|
There is nothing to fear about.
|
|
|
|
|
nothing on the code side... but if its a fast hard drive 10k or an old hard drive
heat might be a problem if the disk is fragmented or poorly ventilated.
overheating kills hard drives very quickly. (my 7.5krpm drive heats up quick not sure if I’d want to be writing data to it for hours without a break).
This is something I've not coded myself but if your application is important you might want to checkout a way to detect the temperature of the hard drive. Not sure, but you could use SMART to get the temperature
Wikipedia entry
Just a thought
|
|
|
|
|
godspeed123 wrote: Is this possible just to take data from memory and constantly write it to hard drive without making it lose any data. Or do I have to do something fancy to ensure this? This data will be continuously coming in for like a few hours.
thats not a problem.. I believe you have heard about virtual memory, it just space reserved in harddisk for memory read/write operation. so you just have to reserve some space for you and continue writing without any fear.. one more question are you able to achieve 5ms accuracy..
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
How does one reserve virtual memory in C++. The data is consistently coming in at 5 ms. I cant acieve no where near that when trying to copy it to harddrive.
|
|
|
|
|
godspeed123 wrote: How does one reserve virtual memory in C++
i am just quoting a exmaple of windows operating system..
godspeed123 wrote: The data is consistently coming in at 5 ms. I cant acieve no where near that when trying to copy it to harddrive.
for that you can make circular queue and write that data into circular queue when coming from port in 5 ms and write from other end..! this way you can able to save your data
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Hi,
I have tried that. The queue writing to the harddrive is too slow.
|
|
|
|
|
I am getting this error as soon as the program executes. It's a dialog-based application. In debug it takes me to the following source code:
_AFXWIN_INLINE void CWnd::SetFont(CFont* pFont, BOOL bRedraw)
{ ASSERT(::IsWindow(m_hWnd)); ::SendMessage(m_hWnd, WM_SETFONT, (WPARAM)pFont->GetSafeHandle(), bRedraw); }
Is this trying to tell me there is a bad handle in the ASSERT section, or a Font problem?
Is there a tutorial that could help?
Many thanks.
John P.
|
|
|
|
|
Probably, you are calling SetFont function on uninitialized CWnd object.
Prasad
MS MVP - VC++
|
|
|
|
|
I don't think that's the real problem. In this particular project, I've added a new dialog by copying and pasting the relevant parts of the dialog from the .RC and resource.h files. I've also added the .CPP and .H files for this dialog to the workspace. Plus the files I copied into the different project worked just fine in the old project from where they were copied. To me, this error just doesn't make sense. Is there anything else that could be the problem due to my copying and pasting from one project to another?
Thanks again.
John P.
|
|
|
|
|
jparken wrote: I don't think that's the real problem.
Actually, that IS the problem. Whatever control you are trying to set the font for has a NULL window handle. Check the call stack when that assertion fires to see where your code is in error.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
David --- I'm having a problem with the underlying logic then. If these same files do not have this problem in the other project (which is identical except for the addition of one new dialog), then why would this error appear in the one with the new dialog, which has not even been called by the system when it first loads up? Or does that not matter in a case like this? I'm going on the assumption that the problem is in the very first dialog that is being called at statrup of this .exe --- poor assumption on my part?
Thanks
John P.
|
|
|
|
|
One possible reason for this would be that when you copy files/resources from one project to another, the controls on the copied dialog may have the same resource id as other controls that you already have.
Open your resource.h file and look for duplicate numbers for the resource IDs. If there are duplicates, renumber them to eliminate the duplicates, the completely rebuild your project.
Hope that helps.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
jparken wrote: Is there a tutorial that could help?
When you're dealing with code that you're not familiar with, usually the fastest way to track down this type of problem is to run the app under the VS debugger, and then look at the stack to see how it got there. The code that you posted is somewhere within the MFC libraries. So what you need to do is to find out how you got there.
The good news is that dialog-based apps are the simplest kind of MFC app. Do you see the dialog at all before the ASSERT error? If not, then there is a good chance that the dialog template in the RC file is incorrect or missing; or the IDD resource id in resource.h doesn't match what's in the RC file, or in the dialog's .h header file. Just make sure everything matches up - for dialog apps, it's pretty straightforward, and will fix this kind of problem 90% of the time.
After making any changes, be sure to recompile everything, to make sure it's all in sync.
Best wishes,
Hans
|
|
|
|
|
Hallo Community,
it would be very nice if anyone could point me possible reasons for the misbehaviour of my MFC-MDI-App.
We want to start the app via DDE '[open("%1")]', which works fine with the app already
running, but fails, if the DDE client has to start the app.
As I've found in an msdn-blog, the calling process waits for the app finishing its initialization by calling 'WaitForInputIdle'.
I've reproduced this calling procedure in an old DDE-Client sample from MSDN (using DDEML, hiding the interesting part), and get the same behaviour: After successfully waiting (return of WaitForInputIdle is 0), the WM_DDE_INITIATE message gets still not send to my apps main window.
If I insert a short time of Sleep between the Wait and the connection attempt in the client, it works fine again.
The question is, what is my app doing/why is the main window not available as target for the DDE-client after WaitForInputIdle() has returned ?
The error message from explorer is 'File xxx not found', which comes before InitInstance is processed.
When the app is started via double-click in explorer using the debugger by defining the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\MYAPP.EXE\debugger=...' everything is working fine again.
Any hints highly appreciated !
Best regards
Reinhard
|
|
|
|
|