|
Thank you!
I asked some of my people. Some one did this job already in my country.I introduced him to the boss. I'm sorry to answer late. It's because I went to sleep yesterday. I eas unable to stay awake even a single second!!!!!!!!!!
Thank you.
Regards
|
|
|
|
|
Hi.
I have an application, (MFC application using VC++ 6.0), runing in all the windows PC OS, (from Windows 98 to Windows XP), and now, I want to run that program in a Palm using Windows CE, (3.0 or 5.0).
The question is: can I migrate that program to windows ce keeping the main development in Visual C++?.
I.E -> I'm using many MFC arrays like CByteArray, CWordArray, CObjetArray, etc.
I'm using serialization.
And many things of MFC., (Dialogs Class and Windows Class, etc)
All this will work in Windows CE 3.0 or 5.0??
Or should I make an all new application using .NET??
Thank you in advance.
Demian.
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my telephone."
-Bjarne Stroustrup, computer science professor, designer of C++
programming language (1950- )
|
|
|
|
|
Demian - usually, it's best to start on Windows CE and go the other way. I've just spent the last 2 years of my life on a Windows CE project. It is still going strong..... It's pure MFC with activeX, dialogs, etc. My experience is that *most*, not all of the desktop will run on Windows CE.
Question 1: Usually, Windows CE devices have much, much smaller screen real-estate. How might this impact your application?
OS Version: At a minimum, 4.2 (MS calls it .net) or just go to 5.0.
As I said above, most will run in CE, but the compiler will let you know what is missing. Serialization has it's limitations. Also watch out for unicode issues.
New app - that all depends... I'd need to know more about what your desktop app does....
Let me know.
C. Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
|
|
|
|
|
Thank you very much Gilley.
But, one more thing. For continue working with VC++ 6.0 and building new applications for Windows CE, should I use Microsoft® eMbedded Visual Tools 3.0 (or later) isn't?
That's what I must to add to my Visual Studio. Or what else?
Thank you.
Demian.
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my telephone."
-Bjarne Stroustrup, computer science professor, designer of C++
programming language (1950- )
|
|
|
|
|
Heh, heh - not laughing at you, just remembering much angst trying to figure out how to do this. The general answer to your question depends on what you want to do philosophically. In any event, you will need to install Embedded Visual C++, a completely separate environment from VS. Version 3.0 is very old, I use 4.0. Don't forget that you will need an SDK. Follow up with any questions...
Options:
- you can use the same code base, pulling it from version control. If you do this, then the
embedded VC++ and VC++ areas need not be the same.
- if you want combined projects / don't use version control, then you tend to toss everything
into the same folder. Since the VS project already exists, you simply create an EVC++ project
in the same location (VS workspace files are .dsw, EVC++ are .vcw), then add the source files
to it.
WARNING! I've only done this with an activeX control project, so try this on a small project first and make backups.
Let me know if I can answer any other questions....
C. Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
|
|
|
|
|
Hello All, I have an application that runs without error on my own system. Even in release mode  . However, when i run the application on other systems, my app reports to me that it was undable to aquire a crypt context (CryptAcquireContext) due to an invalid param.
This code is called in a simple C worker thread. Any Ideas?
<br />
UINT stringHash(byte* message, char* hash){<br />
DWORD hashLen = 16;<br />
<br />
HCRYPTPROV hCryptProv;<br />
HCRYPTHASH hHash;<br />
<br />
<br />
ZeroMemory(&hCryptProv, sizeof(hCryptProv));<br />
ZeroMemory(&hHash,sizeof(hHash));<br />
<br />
BYTE hashedBytes[16];<br />
<br />
<br />
if (!CryptAcquireContext(&hCryptProv, NULL, MS_ENHANCED_PROV, PROV_RSA_FULL, 0)){<br />
CryptReleaseContext(hCryptProv,0);<br />
return GetLastError();<br />
}<br />
<br />
...<br />
|
|
|
|
|
|
knave45 wrote:
if (!CryptAcquireContext(&hCryptProv, NULL, MS_ENHANCED_PROV, PROV_RSA_FULL, 0)){
CryptReleaseContext(hCryptProv,0);
return GetLastError();
}
You are trying to acquire the handle to key container "Microsoft Enhanced
Cryptographic Provider " with the parameter MS_ENHANCED_PROV . The 9x
system may not be having this key container with it. So try to get handle to
some other key container. Or use NULL to get the handle to the default key
container.
If you don't like defaults !! try MS_DEF_PROV which is there with all window
flavors i guess...
--
Best Regards
Suhredayan
suhredayan
There is no spoon.
|
|
|
|
|
Good afternoon,
in MFC'S wincore.cpp line 882......where is the P come from? looks like should be pMap->LookupPermanent(m_hWnd)) or pMap->LookupTemporary(m_hWnd)), but they were both error out in watch window....
CObject* p;
ASSERT((p = pMap->LookupPermanent(m_hWnd)) != NULL ||
(p = pMap->LookupTemporary(m_hWnd)) != NULL);
ASSERT((CWnd*)p == this); // must be us
I got assertin failed on last line, but I don't really understand why is it happening, the last part form my app is going to CDialog::OnOK();
"Many ASSERTs can occur when objects are created in the context of one module or thread state, and used or destructed in another. "......what is this really mean?
|
|
|
|
|
Firstly, in release mode, your ASSERT part will not be executed. Thus, LookupPermanent and LookupTemporary will not be called. Would it affect your program? If so, use VERIFY.
valerie99 wrote:
CObject* p;
ASSERT((p = pMap->LookupPermanent(m_hWnd)) != NULL ||
(p = pMap->LookupTemporary(m_hWnd)) != NULL);
If LookupPermanent returns non-null and LookupTemporary returns null, the assertion will not occur. In this case, the next ASSERT will fail.
<font=arial>Weiye Chen
Life is hard, yet we are made of flesh...
|
|
|
|
|
Thank you, Weiye...
"If LookupPermanent returns non-null and LookupTemporary returns null, the assertion will not occur", I just checked, this is absolutely right, but why is "the next ASSERT will fail. "
what happened is just like you said, but I don't understand why is it happening, when the hash table on LookupTemporary is empty....P will not point to the same address as this?
this is part of MFC's code, my applitaion that using this code is like this:
UINT ThreadFalling(LPVOID pParam)
{
CUsocDlg* pDlg=(CUsocDlg*) pParam;
pDlg->IsThreadRunning=true;
pDlg->Process();
return 0;
}
|
|
|
|
|
What this is saying is that you have one CWnd structure declared that has a given m_hWnd (for example 0x052050) while MFC thinks another CWnd structure is the REAL owner of the m_hWnd.
// Note: if either of the above asserts fire and you are
// writing a multithreaded application, it is likely that
// you have passed a C++ object from one thread to another
// and have used that object in a way that was not intended.
// (only simple inline wrapper functions should be used)
//
// In general, CWnd objects should be passed by HWND from
// one thread to another. The receiving thread can wrap
// the HWND with a CWnd object by using CWnd::FromHandle.
//
// It is dangerous to pass C++ objects from one thread to
// another, unless the objects are designed to be used in
// such a manner.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
|
I have application that scans for files (exe's and dll's) and looks up thei import table.
I have managed to see what functions they import with IMAGE_NT_HEADERS IMAGE_IMPORT_HEADERS IMAGE_THUNK_DATA.
i compare the c***ion pointer from
pThunk->u1.FisrtFunction with my function loaded with GetProcaAdress()
it works fine but how do I get the function name from IMAGE_THUNK_DATA structure
i've tried
WORD hint=(WORD)&pThunk[l]->u1.AddressOfData->Hint;
PSTR FNAME=(PSTR)((BYTE *)hMod+pThunk[l]->u1.AddressOfData->Name[hint]);
doesn't work what is the correct combination ?
gabby
|
|
|
|
|
Hi all,
Is there a simple/efficient way to detect whether user has made any changes to the input fields in a MFC CDialog? i.e unchecking a checkbox or text changes in a text box?
TIA!
LS
|
|
|
|
|
There are events for checking and for text changing. There's no single, overarching method you can call on a dialog tho.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I'm trying to use the Print dialog box in my program. MSDN provides wonderful instruction on how to create the dialog box and display it with certain options, etc., etc., but I can't seem to find from MSDN the code to actually get the ink from the printer to the paper and what to be putting on the paper. I display the dialog, the user can make all kinds of nice selections, but how do I tell it what to print, and how do I make the printer move?
Danny
|
|
|
|
|
Hi,
you should use a DC(attach it to your print dialog printer DC), Start a document->start a page-> do whatever you want with the DC(whatever you do will be printed!)->end your page->end your document
look below:
CPrintDialog PDlg(FALSE);<br />
CDC PDC;<br />
<br />
<br />
<br />
PDC.Attach(PDlg.GetPrinterDC());<br />
<br />
PDC.StartDoc("New Name, will apear in systray");<br />
PDC.StartPage();<br />
<br />
PDC.TextOut(0,0,"HELLO!");<br />
<br />
PDC.EndPage();<br />
PDC.EndDoc();
|
|
|
|
|
I am using VC6 w/ MFC and have an app with the COleDocument/CView architecture. A COleClientItem is added (and activated) successfully to the document but now I would like to get at some of the resource items in that control, namely the icons. I figured I would use the ::LoadIcon and use the instance handle of the control but I don't know how to get it. The GetIconFromRegistry() is not useful  as the control does not register its icon that way. (I wrote the OCX control and if someone knows how to register the icon, that would be fine as well.)
If I go the ::LoadIcon() route, how do I get the instance handle of the control?
Thanks!
|
|
|
|
|
Hi all,
I have been programming all my projects using C++ and MFC for the last 8 years. Now I think it's time for me to learn new things by using .NET when creating new features ( new dialogs, new code) on top of old projects.
Is it possbile for MFC DLL or MFC EXE to call a DLL that was created using .NET languages?
If the answer is yes, what is the best way to share ( pass) data structures between MFC EXE and .NET DLL?
Recommend any good book?
Thanks
|
|
|
|
|
VC++ 7.1 and VC++ 2005 both support the /clr mode, where your entire native code (MFC, ATL whatever) gets compiled into IL (exceptions to this rule exist). Now you can use .NET classes from your (previously)native apps just as if you were using native classes.
|
|
|
|
|
|
Hello I have some problem about Platform SDK using, I need help, but please read carefuly to know the problem and the situation first, Thanks!!!
Problem:
========
Windows Data Types: for examples:
ULONG_PTR
PDWORD_PTR
are undeclared identifier in MFC/VC++/Platform SDK!!!
Installation' situation:
========================
I have intalled the Platform SDK on my computer. The SDK install file was downloaded from MicoSoft website ( Windows® Server 2003 SP1 Platform SDK Web Install ).
The setup file name is:
PSDK-x86.exe.
The address is :
http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3- A93E-40C0EC4F68E5&displaylang=en
Platform SDK files situation:
=============================
After installed, on my computer, under the folder C:\Program Files\Microsoft Platform SDK\Include, I got the file BaseTsd.h, but in the file, there are no these Data types declarations!!!
Ms Platform SDK documentation Say:
==================================
All these Windows Data Types are declared in BaseTsd.h
So, some body can fig out the problem? Thanks
So, some body can fig out the problem? Thanks
So, some body can fig out the problem? Thanks
|
|
|
|
|
rat.crown wrote:
After installed, on my computer, under the folder C:\Program Files\Microsoft Platform SDK\Include, I got the file BaseTsd.h, but in the file, there are no these Data types declarations!!!
So what do you have in the BaseTsd.h file? What size is the file? Is this SDK for Visual Studio 6 or .Net?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
=====================
BaseTsd.h File Size:
=====================
Name Size Modified
BaseTsd.h 9 KB 4/14/2005
==============================================================
Windows® Server 2003 SP1 Platform SDK Web Install Description:
==============================================================
[Overview]
The Microsoft® Windows® Software Development Kit (SDK) provides the documentation, samples, header files, libraries, and tools you need to develop applications that run on Windows. The applications you develop with this edition of the SDK can run on the x86, x64 and Itanium-based versions of Windows Server 2003 SP1, Windows XP SP2, Windows XP x64 Pro Edition, and Windows 2000. A new custom install allows you to select components you wish to install on a more granular level.
[System Requirements]
Supported Operating Systems: Windows 2000; Windows Server 2003; Windows XP 64-bit; Windows XP Professional Edition ; Windows XP Service Pack 1
Development Tools. To build the C/C++ samples, you must have a C/C++ compiler. If you are using Microsoft Visual C/C++®, run it at least once before installing the SDK. This will ensure that the environment variables are correctly configured. To build the Visual Basic samples, you must have Microsoft Visual Basic®. This SDK does not support working with Microsoft Visual C/C++®, 6.0 as support for VC 6.0 has ended. The last SDK that will work with VC 6.0 is the February 2003 Edition, you can order a CD on the fulfillment site. Side by side installations are not supported.
========================
BaseTsd.h File content:
========================
/*++
Copyright (c) Microsoft Corporation. All rights reserved.
Module Name:
basetsd.h
Abstract:
Type definitions for the basic sized types.
Author:
Revision History:
--*/
#ifndef _BASETSD_H_
#define _BASETSD_H_
#if !defined(_MAC) && (defined(_M_MRX000) || defined(_M_AMD64) || defined(_M_IA64)) && (_MSC_VER >= 1100) && !(defined(MIDL_PASS) || defined(RC_INVOKED))
#define POINTER_64 __ptr64
typedef unsigned __int64 POINTER_64_INT;
#if defined(_WIN64)
#define POINTER_32 __ptr32
#else
#define POINTER_32
#endif
#else
#if defined(_MAC) && defined(_MAC_INT_64)
#define POINTER_64 __ptr64
typedef unsigned __int64 POINTER_64_INT;
#else
#if (_MSC_VER >= 1300) && !(defined(MIDL_PASS) || defined(RC_INVOKED))
#define POINTER_64 __ptr64
#else
#define POINTER_64
#endif
typedef unsigned long POINTER_64_INT;
#endif
#define POINTER_32
#endif
#if defined(_IA64_) || defined(_AMD64_)
#define FIRMWARE_PTR
#else
#define FIRMWARE_PTR POINTER_32
#endif
#if _MSC_VER > 1000
#pragma once
#endif
#ifdef __cplusplus
extern "C" {
#endif
typedef signed char INT8, *PINT8;
typedef signed short INT16, *PINT16;
typedef signed int INT32, *PINT32;
typedef signed __int64 INT64, *PINT64;
typedef unsigned char UINT8, *PUINT8;
typedef unsigned short UINT16, *PUINT16;
typedef unsigned int UINT32, *PUINT32;
typedef unsigned __int64 UINT64, *PUINT64;
//
// The following types are guaranteed to be signed and 32 bits wide.
//
typedef signed int LONG32, *PLONG32;
//
// The following types are guaranteed to be unsigned and 32 bits wide.
//
typedef unsigned int ULONG32, *PULONG32;
typedef unsigned int DWORD32, *PDWORD32;
#if !defined(_W64)
#if !defined(__midl) && (defined(_X86_) || defined(_M_IX86)) && _MSC_VER >= 1300
#define _W64 __w64
#else
#define _W64
#endif
#endif
//
// The INT_PTR is guaranteed to be the same size as a pointer. Its
// size with change with pointer size (32/64). It should be used
// anywhere that a pointer is cast to an integer type. UINT_PTR is
// the unsigned variation.
//
// __int3264 is intrinsic to 64b MIDL but not to old MIDL or to C compiler.
//
#if ( 501 < __midl )
typedef [public] __int3264 INT_PTR, *PINT_PTR;
typedef [public] unsigned __int3264 UINT_PTR, *PUINT_PTR;
typedef [public] __int3264 LONG_PTR, *PLONG_PTR;
typedef [public] unsigned __int3264 ULONG_PTR, *PULONG_PTR;
#else // midl64
// old midl and C++ compiler
#if defined(_WIN64)
typedef __int64 INT_PTR, *PINT_PTR;
typedef unsigned __int64 UINT_PTR, *PUINT_PTR;
typedef __int64 LONG_PTR, *PLONG_PTR;
typedef unsigned __int64 ULONG_PTR, *PULONG_PTR;
#define __int3264 __int64
#else
typedef _W64 int INT_PTR, *PINT_PTR;
typedef _W64 unsigned int UINT_PTR, *PUINT_PTR;
typedef _W64 long LONG_PTR, *PLONG_PTR;
typedef _W64 unsigned long ULONG_PTR, *PULONG_PTR;
#define __int3264 __int32
#endif
#endif // midl64
//
// HALF_PTR is half the size of a pointer it intended for use with
// within structures which contain a pointer and two small fields.
// UHALF_PTR is the unsigned variation.
//
#ifdef _WIN64
#define ADDRESS_TAG_BIT 0x40000000000UI64
typedef __int64 SHANDLE_PTR;
typedef unsigned __int64 HANDLE_PTR;
typedef unsigned int UHALF_PTR, *PUHALF_PTR;
typedef int HALF_PTR, *PHALF_PTR;
#if !defined(__midl)
__inline
unsigned long
HandleToULong(
const void *h
)
{
return((unsigned long) (ULONG_PTR) h );
}
__inline
long
HandleToLong(
const void *h
)
{
return((long) (LONG_PTR) h );
}
__inline
void *
ULongToHandle(
const unsigned long h
)
{
return((void *) (UINT_PTR) h );
}
__inline
void *
LongToHandle(
const long h
)
{
return((void *) (INT_PTR) h );
}
__inline
unsigned long
PtrToUlong(
const void *p
)
{
return((unsigned long) (ULONG_PTR) p );
}
__inline
unsigned int
PtrToUint(
const void *p
)
{
return((unsigned int) (UINT_PTR) p );
}
__inline
unsigned short
PtrToUshort(
const void *p
)
{
return((unsigned short) (unsigned long) (ULONG_PTR) p );
}
__inline
long
PtrToLong(
const void *p
)
{
return((long) (LONG_PTR) p );
}
__inline
int
PtrToInt(
const void *p
)
{
return((int) (INT_PTR) p );
}
__inline
short
PtrToShort(
const void *p
)
{
return((short) (long) (LONG_PTR) p );
}
__inline
void *
IntToPtr(
const int i
)
// Caution: IntToPtr() sign-extends the int value.
{
return( (void *)(INT_PTR)i );
}
__inline
void *
UIntToPtr(
const unsigned int ui
)
// Caution: UIntToPtr() zero-extends the unsigned int value.
{
return( (void *)(UINT_PTR)ui );
}
__inline
void *
LongToPtr(
const long l
)
// Caution: LongToPtr() sign-extends the long value.
{
return( (void *)(LONG_PTR)l );
}
__inline
void *
ULongToPtr(
const unsigned long ul
)
// Caution: ULongToPtr() zero-extends the unsigned long value.
{
return( (void *)(ULONG_PTR)ul );
}
#define PtrToPtr64( p ) ((void * POINTER_64) p)
#define Ptr64ToPtr( p ) ((void *) p)
#define HandleToHandle64( h ) (PtrToPtr64( h ))
#define Handle64ToHandle( h ) (Ptr64ToPtr( h ))
__inline
void *
Ptr32ToPtr(
const void * POINTER_32 p
)
{
return((void *) (ULONG_PTR) (unsigned long) p);
}
__inline
void *
Handle32ToHandle(
const void * POINTER_32 h
)
{
return((void *) h);
}
__inline
void * POINTER_32
PtrToPtr32(
const void *p
)
{
return((void * POINTER_32) (unsigned long) (ULONG_PTR) p);
}
#define HandleToHandle32( h ) (PtrToPtr32( h ))
#endif // !_midl
#else // !_WIN64
#define ADDRESS_TAG_BIT 0x80000000UL
typedef unsigned short UHALF_PTR, *PUHALF_PTR;
typedef short HALF_PTR, *PHALF_PTR;
typedef _W64 long SHANDLE_PTR;
typedef _W64 unsigned long HANDLE_PTR;
#define HandleToULong( h ) ((ULONG)(ULONG_PTR)(h) )
#define HandleToLong( h ) ((LONG)(LONG_PTR) (h) )
#define ULongToHandle( ul ) ((HANDLE)(ULONG_PTR) (ul) )
#define LongToHandle( h ) ((HANDLE)(LONG_PTR) (h) )
#define PtrToUlong( p ) ((ULONG)(ULONG_PTR) (p) )
#define PtrToLong( p ) ((LONG)(LONG_PTR) (p) )
#define PtrToUint( p ) ((UINT)(UINT_PTR) (p) )
#define PtrToInt( p ) ((INT)(INT_PTR) (p) )
#define PtrToUshort( p ) ((unsigned short)(ULONG_PTR)(p) )
#define PtrToShort( p ) ((short)(LONG_PTR)(p) )
#define IntToPtr( i ) ((VOID *)(INT_PTR)((int)i))
#define UIntToPtr( ui ) ((VOID *)(UINT_PTR)((unsigned int)ui))
#define LongToPtr( l ) ((VOID *)(LONG_PTR)((long)l))
#define ULongToPtr( ul ) ((VOID *)(ULONG_PTR)((unsigned long)ul))
#if !defined(__midl)
__inline
void * POINTER_64
PtrToPtr64(
const void *p
)
{
return((void * POINTER_64) (unsigned __int64) (ULONG_PTR)p );
}
__inline
void *
Ptr64ToPtr(
const void * POINTER_64 p
)
{
return((void *) (ULONG_PTR) (unsigned __int64) p);
}
__inline
void * POINTER_64
HandleToHandle64(
const void *h
)
{
return((void * POINTER_64) h );
}
__inline
void *
Handle64ToHandle(
const void * POINTER_64 h
)
{
return((void *) (ULONG_PTR) (unsigned __int64) h );
}
#endif
#define Ptr32ToPtr( p ) ((void *) p)
#define Handle32ToHandle( h ) (Ptr32ToPtr( h ))
#define PtrToPtr32( p ) ((void * POINTER_32) p)
#define HandleToHandle32( h ) (PtrToPtr32( h ))
#endif // !_WIN64
#define HandleToUlong(h) HandleToULong(h)
#define UlongToHandle(ul) ULongToHandle(ul)
#define UlongToPtr(ul) ULongToPtr(ul)
#define UintToPtr(ui) UIntToPtr(ui)
#define MAXUINT_PTR (~((UINT_PTR)0))
#define MAXINT_PTR ((INT_PTR)(MAXUINT_PTR >> 1))
#define MININT_PTR (~MAXINT_PTR)
#define MAXULONG_PTR (~((ULONG_PTR)0))
#define MAXLONG_PTR ((LONG_PTR)(MAXULONG_PTR >> 1))
#define MINLONG_PTR (~MAXLONG_PTR)
#define MAXUHALF_PTR ((UHALF_PTR)~0)
#define MAXHALF_PTR ((HALF_PTR)(MAXUHALF_PTR >> 1))
#define MINHALF_PTR (~MAXHALF_PTR)
//
// SIZE_T used for counts or ranges which need to span the range of
// of a pointer. SSIZE_T is the signed variation.
//
typedef ULONG_PTR SIZE_T, *PSIZE_T;
typedef LONG_PTR SSIZE_T, *PSSIZE_T;
//
// Add Windows flavor DWORD_PTR types
//
typedef ULONG_PTR DWORD_PTR, *PDWORD_PTR;
//
// The following types are guaranteed to be signed and 64 bits wide.
//
typedef __int64 LONG64, *PLONG64;
//
// The following types are guaranteed to be unsigned and 64 bits wide.
//
typedef unsigned __int64 ULONG64, *PULONG64;
typedef unsigned __int64 DWORD64, *PDWORD64;
//
// Thread affinity.
//
typedef ULONG_PTR KAFFINITY;
typedef KAFFINITY *PKAFFINITY;
#ifdef __cplusplus
}
#endif
#endif // _BASETSD_H_
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
