|
Hey all. I'm working on a MFC Single Doc program. I have included:
<br />
m_pMainWnd->ShowWindow(SW_SHOWMAXIMIZED);<br />
m_pMainWnd->UpdateWindow();<br />
It is maximizing the program correctly. My problem is that when it loads, it is not the active program. Any help on how to fix this is appreciated.
Brad Jennings
|
|
|
|
|
|
Thanks a lot. Not exactly what I was looking for but the answer wasn't far off. I just needed to add the line:
<br />
m_pMainWnd->SetForegroundWindow();<br />
Later.
Brad Jennings
|
|
|
|
|
Hello, can anyone tell me how to minimize a dialog box programatically to
the system tray on start up. Like MSN messanger or ICQ.
Thank You
|
|
|
|
|
if you want a taskbar icon, see http://www.codeproject.com/shell/cjbtaskbarapplet.asp
-c
Alcohol is the anesthesia by which we endure the operation of life.
-- George Bernard Shaw
|
|
|
|
|
It crashes at the update().I checked to see that there was valid data in in the fields after being assigned.
while (!m_db1.m_pRecordset->GetadoEOF ())
{
m_db3.Open(DatabaseName3);
int n = m_db3.m_pRecordset->RecordCount;
m_db3.m_pRecordset->AddNew();
std::set<CString>::iterator itA = m_set3.begin();
for(; itA != m_set3.end(); itA++)
{
tempStr = *itA;
char* fldIt1 = new char [tempStr.GetLength() + 1];
strcpy(fldIt1, tempStr);
CString strTemp((char*)(_bstr_t)(m_db1.m_pRecordset->Fields->Item[fldIt1]->Value));
m_db3.m_pRecordset->Fields->Item[fldIt1]->Value = m_db1.m_pRecordset->Fields->Item[fldIt1]->Value;
;
delete[] fldIt1;
}
m_db1.m_pRecordset->MoveNext();
m_db3.m_pRecordset->Update();
m_db3.m_pRecordset->Close();
m_db3.m_pRecordset = NULL;
m_db3.Close();
}
|
|
|
|
|
You have MoveNext before the Update.
|
|
|
|
|
Thanks. But actually thats the movenext for a different database. I'm cycling through 1 and adding to another.....but thank you anyway
ns
I did find my problem a few minutes ago (hurrah!). I had added and populated a field in the new databse, but didnt realize I had to close and reopen it for the change to be visible to the program. Once I did that things are going along fine!
|
|
|
|
|
nss wrote:
Thanks. But actually thats the movenext for a different database. I'm cycling through 1 and adding to another.....but thank you anyway
ns
Ooops.
nss wrote:
I did find my problem a few minutes ago (hurrah!). I had added and populated a field in the new databse, but didnt realize I had to close and reopen it for the change to be visible to the program. Once I did that things are going along fine!
Which database are you using, and what version of ADO? I had a similar problem with an Access 97 database, with the field not updating unless I closed and reopened the recordset. It turned out to be a bug in the Jet driver for 97, so moving to Access 2000 DB fixed it, so that when I called update the correct value was there.
|
|
|
|
|
Access 2000. What it was unhappy about was that I was trying to access a value from the ew column, and even though if I looked in Access, the new column was added, apparently the code was clueless. Its msado25.tlb. Was using a later version, with msado15, but it wouldnt run on some machines - an MDAC mismatch.
I should add that the problem was with the database I was reading from (to which I'd added a column), but once the open-close thing was resolved, tht database I was writing to, and updating had no problem. I didnt have to close and open it multipe times...
|
|
|
|
|
Hi,
I would need some fuction like FromHandle but only in Win32.
???
R.
|
|
|
|
|
If you're using the APIs, then there are no wrapper classes. HWND is all there is.
--Mike--
"I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
What do you mean? There is no CWnd in plain Win32 API if you do not use MFC extensions
modified 12-Sep-18 21:01pm.
|
|
|
|
|
I just wanted to do this conversion in a non CWnd derived class (e.g: CMyApp).
R.
|
|
|
|
|
The class needs not be derived from CWnd, but you need MFC to convert a HWND to CWnd
modified 12-Sep-18 21:01pm.
|
|
|
|
|
But in CMyWinApp
CWnd::FromHandle() is unavailable.
But I need to convert a handle to a pointer.
R.
|
|
|
|
|
a pointer to what?
Alcohol is the anesthesia by which we endure the operation of life.
-- George Bernard Shaw
|
|
|
|
|
CWnd::FromHandle() is a static member
function. It will, if necessary, create
a temporary CWnd object and return a
pointer to that. Like so:
CWnd* pTmpWnd=CWnd::FromHandle(hSomeWnd);
Call it from anywhere.
|
|
|
|
|
Scott,
thanks for the solution!
R.
|
|
|
|
|
A CWnd is a wrapper for a HWND, and if you're in Win32, you won't have anything that takes or uses a CWnd. Perhaps if you explained what you were trying to do, I suspect the problem is your approach in general, and not the specific question you're asking.
Christian
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
During last 10 years, with invention of VB and similar programming environments, every ill-educated moron became able to develop software. - Alex E. - 12-Sept-2002
|
|
|
|
|
Christian,
I plan to write an app which connects to external running instances of IE. This is a dialog based app with MFC support. However, the actual work
(HTML parsing) is done in my CMyWinApp class, in my dialog I only handle the settings.
SHDocVw::IShellWindow returns all IWebBrowser pointers, and SHDocVw::IWebBrowser2::get_HWND returns the handle of an external IE Window, and I wanna make the topmost of them the parent
window of my dialog which should be done when constructing the dialog.
(CMyDialog dlg(pWnd)). Since the dialog is constructed in CMyWinApp in case of an MFC application, I have to convert the extracted HWND handle to a CWnd* pointer. Fortunately, CWnd::FromHandle is a static
function, so I can make this conversion in CMyWinApp, too. Since I didn't know that, I couldn't use it.
10x to Scott for pointing this out.
10x to you, too, for helping to see clear in this question.
R.
|
|
|
|
|
I want to know how to put a background bitmap (like a watermark)in my CEdit/CRichEdit ctrl. Can somebody help?
|
|
|
|
|
CRichEdit has a way to set its background as transparent, but i have never used it so can't tell how to do it. You could set the container's background and place the CRichEdit object over.
Otherwise, derive a class CNewEdit from CEdit and override as follows:
HBRUSH CNewEdit::CtlColor(CDC* pDC, UINT nCtlColor)
{
pDC->SetBkMode(TRANSPARENT);
return (HBRUSH)GetStockObject(WHITE_BRUSH);
}
BOOL CNewEdit::OnEraseBkgnd(CDC* pDC)
{
pDC->BitBltStuff();
return 0;
}
rechi
|
|
|
|
|
Hi
Can I assume that if some application is using some dll, this dll will be in memory till the application terminates? I want to store some data in dll, so this is quite important for me. I'm also not sure if there is always one instance of dll, shared amongst all applications using the dll (I want to share data stored in dll between applications). Thanks in advance for the answer.
Greetings
Mariusz Popiolek
|
|
|
|
|
No, you cannot assume that. DLLs are not always loaded at the start of an application and then removed from memory at the end of the application. An app can call LoadLibrary() to grab your DLL and then FreeLibrary() as soon as it's done with it. There is nothing stopping an app from doing this.
A DLL is not a self-standing process. It is only a collection of code and variable definitions with no execution startup code. When an application loads a DLL, all of the DLL's static data variables (eg. global) are created in the calling process's address space, in addition to a table of function pointers. These variables are unique for every process that might load the DLL. The actual code inside a DLL is shared between processes, since it's simply a set of instructions on how to go about it's business.
If you allocate memory inside a DLL function, that block of memory is located within the heap of the calling application that loaded the DLL and called the function. You cannot share memory between processes by just creating a global variable (or a static variable inside a function) and reading/writing it in the calling app. Those variables simply can't be shared between processes by default.
That said, there are ways to go about the task of sharing memory. You can create a shared memory block within your DLL code that is open to any and all applications that want to use it. Technically, you don't really need a DLL to do this, but it's helpful for having a common codebase with which to create and get at the memory object.
Take a look at these functions:
CreateFileMapping()
MapViewOfFile()
The docs on these functions indicate they're used for mapping files into memory. Which is true. But if you pass INVALID_HANDLE_VALUE to CreateFileMapping(), you can build a memory object with a unique name that can then be "mapped" by any process that chooses to do so. That's where MapViewOfFile() comes in.
Something like this:
LPVOID CreateABuffer( DWORD SizeOfYourBuffer )
{
HANDLE hMemory = CreateFileMapping(
(HANDLE)0xFFFFFFFF,
NULL,
PAGE_READWRITE,
0,
SizeOfYourBuffer,
"Name you want to call it"
);
if( hMemory == NULL )
{
return NULL or do something creative;
}
LPVOID lpMemory = MapViewOfFile(
hMemory,
FILE_MAP_WRITE,
0,
0,
SizeOfYourBuffer
);
CloseHandle( hMemory );
if( lpMemory == NULL )
{
return NULL;
}
return lpMemory;
}
Here's what happens. The very first call to CreateFileMapping() will allocate the shared memory block. So long as that buffer still has handles open to it, it will not be wiped away. Subsequent calls to CreateFileMapping() with the same name will simply get a pointer to that shared block and will not create a new buffer. MapViewOfFile() is required to actually get a useful pointer to the memory, since CreateFileMapping() returns a HANDLE.
You will need to also call UnMapViewOfFile() when you're done with the buffer. Internally, the shared memory block has a reference counter that increments every time a calling process maps into it. You also have to close the handle to the buffer, as that is also counted and the buffer will not be freed until all handle references are removed. I've done that in the above code. You may wonder why it's done immediately after the MapViewOfFile() command. I did it there so as to not have to worry about cleanup. This won't blow away the buffer; so long as the mapping was successful, the reference counter was incremented and the buffer will stay in memory.
That's it for sharing data between apps inside your DLL. Keeping it alive until the app terminates would have to be enforced by the people writing the application; you can't specify that yourself. A solution there would be to create your own dummy EXE that loads the DLL and it hangs around forever, like an NT service or something.
Ty
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Albert Einstein
|
|
|
|