|
Hi,
I've a question relating to IE.
I'm opening IE from VC, and passing a .htm file as command line arg. It opens fine.
But when I call it for the second time it opens in a new IE window, but I dont want this to happen. What should be done?
Yuvarajan JT
|
|
|
|
|
I have declared a function called Solve like this :
double Solve(double (pFn) (double), double pX);
Here the code for pFn :
double pFn(double pU)
{
return pow( pU*3.14-1.5, 3 );
}
I would like to know how to use the function Solve , which is needed to solve : pFn(X) = X ?
Thank in advance for your help.
Joe
|
|
|
|
|
Do your homework by yourself!!
|
|
|
|
|
VERY VERY FUNNY ANSWER !
I don't know how old are you, but I guess : 10-13.
Don't forget : "Boys will be Boys !", It is so true...
Joe
|
|
|
|
|
Hi,
Could anyone please show me an example how to create a hidden window? Thank you very much.
|
|
|
|
|
Just call ShowWindow with SW_HIDE.
|
|
|
|
|
Hi,
Does anyone have any tips or pointers for capturing an entire screen of other monitors other than primary monitor? Thank you very much.
|
|
|
|
|
Hi,
Could you please tell me how to use
HMENU GetMenu(
HWND hWnd // handle to window
);
function to get HMENU of Start Menu and Context Menu(right-click)? I use
GetMenu(GetForegroundWindow()) to get HMENU for standard application menu, but I don't know how to get HMENU for Start Menu and Context Menu(right-click). Could you please show me how. Thank you very much.
|
|
|
|
|
Hi,
I am trying to use
BOOL RegisterHotKey(
HWND hWnd,
// window to receive hot-key notification
int id,
// identifier of hot key
UINT fsModifiers,
// key-modifier flags
UINT vk
// virtual-key code
);
in my Win32 DLL. I have questions about what to pass to the first parameter. Can I create a hidden window in my DLL and pass its handle to the first parameter of RegisterHotKey function? And then I can process messages received by the hidden window? If this is a way to do it, could you please show me and give me some pointers how to do it, thank you very much. Or do you have any other easy ways to do this? Please let me know, thank you a lot.
|
|
|
|
|
If you pass NULL as first parameter, WM_HOTKEY messages are posted to the message queue of the calling thread and must be processed in the message loop - no window procedure will receive them. If you create hidden window and pass its handle to RegisterHotKey, the window should receive the message. Of course, the calling thread needs a message queue.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
#include <stdio.h>
main(t,_,a)
char *a;
{
return !
0
|
|
|
|
|
Are you sure this code is true ???
I'm confused
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
This is obviously an entry into the obsfucated code contest - is it the winner ?? ( 12 days of Xmas )
Anyhow, I don't know the details, but it is clearly recursive. If you want to figure it out, I'd start by blocking the code logically, it's obviously set out to make it more unclear as it stands.
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
|
This is one of the 1988 winners of the IOCCC (phillipps.c). You can find lots of similar "interesting" abuses of the C language at IOCCC
|
|
|
|
|
Hi all,
not using MFC for my latest prj, and having a few concerns about character portablily. These are the two approaches I've come up with, but I have no idea what I'm doing, so if anyone can give me a pointer I'll be very grateful
1. -- typedefs:
#ifdef _UNICODE
typedef wstring tstring
#else
typedef string tstring
#endif
2. -- _TCHAR strings:
typedef basic_string<_TCHAR> tstring
....
which would you use? would you use either?
cheers & happy coding
nb
|
|
|
|
|
I use this:
typedef std::basic_string<TCHAR> _tstring Don't forget that I/O streams have different versions too:
#ifdef _UNICODE
#define _tcout wcout;
#define _tcin wcin;
#define _tcerr wcerr;
#else
#define _tcout cout;
#define _tcin cin;
#define _tcerr cerr;
#endif
--Mike--
http://home.inreach.com/mdunn/
"Holding the away team at bay with a non-functioning phaser was an act of unmitigated gall. I admire gall."
-- Lt. Cmdr. Worf
|
|
|
|
|
thanks Michael
think we need more stl warriors in this MFC-polluted world...
nb
|
|
|
|
|
One thing you need to be clear on - do you want to be able to create a single exe that works on both ASCII and UNICODE systems, or do you want to create a code base that can be compiled into an ASCII exe and a separate UNICODE exe ?
The entire 'TCHAR' concept that microsoft has developed is for creating a single set of source that can be compiled into both ASCII and UNICODE versions. If you are writing a program that will only be ASCII, or only UNICODE, or if you a writing a program that must be able to handle both, then the TCHAR style of coding is useless.
The TCHAR/typedef approach might seem like a good idea, but there are much more significant differences between ASCII and UNICODE code other than the size of the storage uhit (8 bit or 16 bit) - for example, upper/lower case conversion is completely different between ASCII and UNICODE, so a function like :
"void ToUpper(_tstring& input);"
is of limited value, since although it will compile into ASCII and UNICODE versions, it will probably only work correctly in one or the other!
In general, I have found that if Unicode is required, or likely to be needed, it's better just to write the entire program in std::wstring, and convert to/from ASCII(std::string) at the "edges".
|
|
|
|
|
It is always usefull to use TCHAR, this will help port the code in the future! You might not wan't unicode at the moment, but in the future who knows?
|
|
|
|
|
You have missed the point - TCHAR addresses the storage issue (8 bit versus 16 bit), but nothing else.
When you say something like : "You might not wan't unicode at the moment, but in the future who knows?", you are implying that the only thing that is different between a UNICODE string and an ASCII string is it's size. This is completely incorrect! A program that is written using TCHAR is NOT a UNICODE program - it is a program that uses 16 bits to store each ASCII character. If "in the future" you really do want a UNICODE program, then you will have to review and probably rewrite any and all code that actually examines the strings in any way (especially I/O code), to reflect to details of the UNICODE specification.
There are two main reasons to use UNICODE in a Windows program.
1. Efficiency. Since NT/2000/XP are all UNICODE systems internally, you avoid the 'thunking' layer of the 'A' versions of the API if you use the native 'W' versions (turned on by "#define _UNICODE"). In this case you get some sort of efficiency gain, but you re NOT writing a true UNICODE program - you are writing a UNICODE program that uses only the ASCII subset. Of course you can do this, but do not fool yourself into believeing you are writing a UNICODE program!
2. True UNICODE. In this case you are writing a program that needs to deal with Asian, Middle Eastern or European languages. UNICODE gives you the ability to store all of these, but you must work carefully to write code that works with strings - TCHAR is of no use at all for this!
I have found that if you are using UNICODE for point(1), then TCHAR has value - it allows you to write one code base, then compile it into different exe's - one ASCII, one UNICODE. The UNICODE version will have a slight performance boost.
However, if you are writing UNICODE for reason (2), then I have found TCHAR to be more trouble than it is worth - it constantly 'hides' the real type, and allows code to be written that will com;ile in different environments, but which does not correctly run in thise environments - in other words, it is very dangerous to write 'library' code using TCHAR, and then assume that it actually is UNICODE compliant.
|
|
|
|
|
USES_CONVERSION;
A2W("I agree with you.");
(2b || !2b)
|
|
|
|
|
I try to create an image app based on Sam Teach Yourself Visual C++ in 21 Days chapter - 8 - Adding Flash--Incorporating Graphics, Drawing, and Bitmaps. The example shows that in order to load an image requires some kind of open file function, but I don’t want to use that function. I want to load my image that I’ve initialized. So I didn’t use some functions mentioned on the example, and it caused an error. The error is saying :
Debug Assertion failed. File afxwin1.inl. Line 418.
And the code is :
// ImageDlg.cpp : implementation file
void CImageDlg::OnBitmap()
{/*I did’t use this function to load the image
// Build a filter for use in the File Open dialog
static char BASED_CODE szFilter[] = "Bitmap Files (*.bmp)|*.bmp||";
// Create the File Open dialog
CFileDialog m_ldFile(TRUE, ".bmp", m_sBitmap,
OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, szFilter);
// Show the File Open dialog and capture the result
if (m_ldFile.DoModal() == IDOK)
{
// Get the filename selected
m_sBitmap = m_ldFile.GetPathName();
// Load the selected bitmap file
HBITMAP hBitmap = (HBITMAP) :LoadImage(AfxGetInstanceHandle(),
m_sBitmap, IMAGE_BITMAP, 0, 0,
LR_LOADFROMFILE | LR_CREATEDIBSECTION);
// Do we have a valid handle for the loaded image?
if (hBitmap)
{
// Delete the current bitmap
if (m_bmpBitmap.DeleteObject())
// If there was a bitmap, detach it
m_bmpBitmap.Detach();
// Attach the currently loaded bitmap to the bitmap object
m_bmpBitmap.Attach(hBitmap);
}
*/the function to load the image end here
// But I used this function to load the image
m_bmpBitmap.LoadBitmap(IDB_BITMAP2);
// Invalidate the second dialog window
m_dlgImage.Invalidate();
}
}
// ImageDialog.cpp : implementation file
void CImageDialog::ShowBitmap(CPaintDC *pdc, CWnd *pWnd)
{
// Convert the pointer to a pointer to the main dialog class
CImageDlg *lpWnd = (CImageDlg *)pWnd;
BITMAP bm;
// Get the loaded bitmap
lpWnd->m_bmpBitmap.GetBitmap(&bm);
CDC dcMem;
// Create a device context to load the bitmap into
dcMem.CreateCompatibleDC(pdc);
// Select the bitmap into the compatible device context
CBitmap* pOldBitmap = (CBitmap*)dcMem.SelectObject(lpWnd->m_bmpBitmap);
CRect lRect;
// Get the display area available
GetClientRect(lRect);
lRect.NormalizeRect();
// Copy and resize the bitmap to the dialog window
pdc->StretchBlt(10, 10, (lRect.Width() - 20),
(lRect.Height() - 20), &dcMem, 0, 0,
bm.bmWidth, bm.bmHeight, SRCCOPY);
}
void CImageDialog::OnPaint()
{
CPaintDC dc(this); // device context for painting
// Get a pointer to the parent window
CImageDlg *pWnd = (CImageDlg *)GetParent();
// Do we have a valid pointer?
if (pWnd)
{
// Is there a bitmap selected and loaded? I didin’t use this function
//if (pWnd->m_sBitmap != "")
// I use this function to Display the image
ShowBitmap(&dc, pWnd);
}
}
what should I do if I don’t use the function (pWnd->m_sBitmap != "") .
Thanks a lot of for helping
Kathrin
|
|
|
|
|
// Delete the current bitmap
if (m_bmpBitmap.DeleteObject())
// If there was a bitmap, detach it
m_bmpBitmap.Detach();
Why do you delete the bitmap and then detach it ?
In any case, if you want to write an imaging program, buy Windows Graphics Programming by Feng Yuan.
As to your question - why can't you check if the filename is valid ? I'd probably suggest that if there is a possibility that your program does not have a bitmap loaded, that this is a flaw to start with, or are you using this filename for saving ? If the former, you could instead check that the bitmap itself is valid. The easiest way to do that is to make it a pointer and check if it is NULL ( don't forget to set it to NULL to start with ).
I'm sorry if I've missed the point, it's great you posted some code in reference to your question, but there is so much code that I'm not sure what you're asking.
Do I read this correctly that your program is dialog based and has two dialogs open ?
Final comment - Hungarian notation can be a bit redundant - m_bmpBitmap is a tautology.
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
|
Thank you for your e-mail.
Yes, you're right, my program is dialog based and has two dialogs open. But I don’t think you get my point.
I remarked the function you mentioned, so my code is like this:
// ImageDlg.cpp : implementation file
void CImageDlg::OnBitmap()
{
// I used this function to load the image
m_bmpBitmap.LoadBitmap(IDB_BITMAP2);
// Invalidate the second dialog window
m_dlgImage.Invalidate();
}
And the rest of my code is the same as my previous letter.
Now, can you tell me what’s wrong with my program?
Thank for your help.
Kathrin
|
|
|
|
|
Kathrin,
If you don't want to change too much of the code, update the oinit dialog method to include the m_bmpBitmap line. OnBitmap should only have the Invalidate line; comment out everything else in the OnBitmap method. Your child dialog window to which the painting is done should be as you have it in your thread posting.
BOOL CImageDlg::OnInitDialog()
{
//...
m_bmpBitmap.LoadBitmap(IDB_BITMAP2);
return TRUE;
}
void CImageDlg::OnBitmap()
{
// COMMENT out all other code.
m_dlgImage.Invalidate();
}
void CImageDialog::OnPaint()
{
CPaintDC dc(this); // device context for painting
// Get a pointer to the parent window
CImageDlg *pWnd = (CImageDlg *)GetParent();
// Do we have a valid pointer?
if (pWnd)
{
ShowBitmap(&dc, pWnd);
}
}
This assumes that the dialog resource was loaded correctly. The Bitmap button on the application window then turns into a refresh button.
Cheers,
-Erik
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My thoughts are my own and reflect on no other.
|
|
|
|
|