|
If you are creating an MDI app, then you need to create a separate view and document for each type of view you wish to display. Use your app class InitInstance function to add the new doc/view to your template. Do some searching at www.msdn.microsoft.com.
I am sitting in my flame proof buncker, so don't even bother.
by the way, perl stinks.
|
|
|
|
|
Here is an out of control bot. Once the ok dialog button is clicked, the bot works ok, but there is no way to interact with the status bar icon. Before ok is clicked, status icon is responsive, but after clicking, there is no answer, and the only way to interrupt the routine is under debug or by ctl-alt-del shutdown of the process.
I've got one of the much-sought-after free G-Mail account to the first person who can find the mistake here.
Here is an outline of the code:
in BotDlg.h
#define WM_TRAY_NOTIFY WM_USER + 0
...
...
class CBotDlg : public CDialog
{
// Construction
public:
CBotDlg(CWnd* pParent = NULL); // standard constructor
LRESULT OnTrayNotify(WPARAM wParam, LPARAM lParam);
void TakeABreak();
void BackToWork();
void OnMenuExit();
NOTIFYICONDATA m_nTrayData;
bool m_bOnBreak;
bool m_bHidden;
...
...
in BotDlg.cpp
...
...
BEGIN_MESSAGE_MAP(CBotDlg, CDialog)
ON_WM_SYSCOMMAND()
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
ON_MESSAGE (WM_TRAY_NOTIFY, OnTrayNotify)
ON_COMMAND(IDC_BREAK, CBotDlg::TakeABreak)
ON_COMMAND (IDC_WORK, CBotDlg::BackToWork)
ON_COMMAND (IDC_EXIT, CBotDlg::OnMenuExit)
ON_BN_CLICKED(IDOK, OnBnClickedOk)
END_MESSAGE_MAP()
...
...
m_nTrayData.cbSize = sizeof(NOTIFYICONDATA);
m_nTrayData.hWnd = m_hWnd;
m_nTrayData.uID = 0;
m_nTrayData.hIcon = LoadIcon (AfxGetInstanceHandle(), MAKEINTRESOURCE(IDI_BREAK));
m_nTrayData.uCallbackMessage = WM_TRAY_NOTIFY;
strcpy (m_nTrayData.szTip, "Bot");
m_nTrayData.uFlags = NIF_ICON | NIF_MESSAGE | NIF_TIP;
m_bOnBreak = false;
m_bHidden = false;
return TRUE; // return TRUE unless you set the focus to a control
...
...
// ******************************
// * *
// * Main Process *
// * *
// ******************************
//
// Main Process
//
void CBotDlg::OnBnClickedOk()
{
//go retrieve web pages and follow links
//til no more links
EndDialog(0);
}
// ******************************
// * *
// * OnTrayNotify *
// * *
// ******************************
//
// Tray Notification Handler
//
LRESULT CBotDlg::OnTrayNotify(WPARAM wParam, LPARAM lParam)
{
// ---- Left-button dclick: Exit Program
if (lParam == WM_LBUTTONDBLCLK)
{
Shell_NotifyIcon(NIM_DELETE, &m_nTrayData);
EndDialog(0);
}//end if
// ---- Right-button down: Pop-up menu
if (lParam == WM_RBUTTONDOWN)
{
CMenu menu;
VERIFY (menu.LoadMenu(IDR_MENU1));
CMenu* pPopup = menu.GetSubMenu(0);
ASSERT(pPopup != NULL);
CRect screen;
GetDesktopWindow()->GetWindowRect(screen);
pPopup->TrackPopupMenu(TPM_LEFTALIGN | TPM_RIGHTBUTTON, screen.right, screen.bottom, AfxGetMainWnd());
}//end if
return LRESULT(0);
}
// ******************************
// * *
// * BackToWork *
// * *
// ******************************
//
// Back to Work Handler
//
void CBotDlg::BackToWork()
{
m_nTrayData.hIcon=LoadIcon(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDI_WORK));
strcpy (m_nTrayData.szTip, "Bot");
m_nTrayData.uFlags = NIF_ICON | NIF_TIP;
Shell_NotifyIcon (NIM_MODIFY, &m_nTrayData);
}
// ******************************
// * *
// * TakeABreak *
// * *
// ******************************
//
// Take A Break Handler
//
void CBotDlg::TakeABreak()
{
m_nTrayData.hIcon=LoadIcon(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDI_BREAK));
strcpy (m_nTrayData.szTip, "Bot");
m_nTrayData.uFlags = NIF_ICON | NIF_TIP;
Shell_NotifyIcon (NIM_MODIFY, &m_nTrayData);
}
|
|
|
|
|
I have no use for the "much sought after" GMail account, but perhaps I can solve your problem.
I assume that you are talking about an System Tray area icon that is created and maintained by the program. Now, it seems that after you end the dialog by clicking the Ok-button, you also destroy the dialog window. This window is also marked as the parent of the tray area icon (it's message map has a hander for the tray notification). When the window is destroyed, the tray area icon has no window attached to it, and it will start to behave irrationally.
The way to fix this is to move the adding of the tray area icon INSIDE the dialog's main initialization code (to CDialog::OnInitDialog, for example). Then you should create a supplementary function (call it, for example, CBotDlg::DestroyTrayIcon). This function is responsible for removing the icon from the tray area.
Now go through your code. Everywhere where you are calling CDialog::EndDialog, you should add a call to CBotDlg::DestroyTrayIcon before the EndDialog call. This makes sure that once the dialog window is destroyed, the tray area icon no longer exists, and can no longer cause irrelevant behaviour.
If your idea is to create and upkeep the tray area icon AFTER the dialog has been destroyed, then you need to create another window that is responsible for handling messages sent by the tray icon. The basic idea is that the tray area icon is always bound to an existing window. If this window gets destroyed with the tray area icon still there, it will lead to unpredictable behaviour.
UPDATE: After reading more of your code sample, it became apparent that your problem is in the dialog window. The tray area icon is bound to the dialog window, but you're destroying the window when EndDialog is called. This leads the tray icon to stop responding. Fixing it is easy: instead of ending the dialog, use ShowWindow to hide the window from sight (minimize to tray), or create a dummy window with no other purpose than to answer to the tray area notifications.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Kitos for the suggestions, but the dialog box doesn't get destroyed until the end of the main routine. The main routine can run for days, that's why I need to interrupt it sometimes. End dialog only happens at the end and then everything appears to terminate normally.
I have experimented with early enddialog and hiding and minimizing the dialog box. You're right, early enddialog leads to unpredictable results. What is also curious and probably related is that when the ok button is clicked, the resulting minimized window also becomes unresponsive, i.e., can't repaint it by clicking on it.
|
|
|
|
|
move ur return LRESULT(0) within the parantheses.It shud work.
|
|
|
|
|
You mean into the prior if statement?
|
|
|
|
|
move the return LRESULT(0) within the brackets.
|
|
|
|
|
The problem is the EndDialog(0) inside your OK button handler. Once EndDialog() is called, the window is destroyed, so any messages that get sent to it are lost, including the ones from the tray icon. Instead of calling EndDialog(), call ShowWindow(SW_HIDE) to merely hide the window without destroying it.
<rant>
Don't you dare offer me a g**** account. If I hear about it one more time I am likely to go insane. Anyone who mentions it should be executed on the spot.
</rant>
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"
|
|
|
|
|
This solution also makes no changes in the icon behaviour, or anything else.
|
|
|
|
|
void CBotDlg::OnBnClickedOk()
{
//go retrieve web pages and follow links
//til no more links
::Shell_NotifyIcon(NIM_DELETE,&m_nTrayData);
this->EndDialog(0);
}
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
This solution didn't work. Nothing changed at all not better or worse.
|
|
|
|
|
Hian your code has million of problem,i am emailing you a working applictaion based on your code
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
typedef FT_STATUS (WINAPI *PtrToOpen)(PVOID, FT_HANDLE *);
PtrToOpen m_pOpen;
FT_STATUS Open(PVOID);
FT_STATUS CBitBangDemoDlg::Open(PVOID pvDevice)
{
if (!m_pOpen)
{
AfxMessageBox("FT_Open is not valid!");
return FT_INVALID_HANDLE;
}
return (*m_pOpen)(pvDevice, &m_ftHandle );
}
Can someone tell me wat this means.And especially wat that WINAPI is.
reeves.
|
|
|
|
|
In WinDef.h you can see that it can be
#define WINAPI CDECL
or
#define WINAPI __stdcall
or
#define WINAPI
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
It's meant to replace the PASCAL calling convention that was used in 16-bit Windows.
Jeremy Falcon
|
|
|
|
|
Hi everyone,
Is there an IStream like interface that I can use for stream like writing into physical memory. I know there is a MemoryStream class in .NET but I cannot use it for my current needs.
I have a binary file format that is OLE2 storage based. However, I cannot use the IStream interface directly and need an IStream like interface to physical memory.
Thanks,
Sincerely,
Pankaj
Without struggle, there is no progress
|
|
|
|
|
pankajdaga wrote:
Is there an IStream like interface that I can use for stream like writing into physical memory.
No, there is no COM interface for writing to a memory location. Why would you want one?
pankajdaga wrote:
I have a binary file format that is OLE2 storage based. However, I cannot use the IStream interface directly and need an IStream like interface to physical memory.
Are you saying that you have loaded a OLE2 compound file into memory but don't have access to the IStream interface so you want to access the memory directly? That does not sould like a good idea. Why don't you have access to the IStream interface?
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
Hi,
Thanks for replying.
My problem is that my specifics state that I need to manipulate the data in the memory and should write to disk only on demand. The IStream interface writes to disk and I was wondering if the same functionality could be achieved in the physical store instead of the virtual one.
Thanks,
Pankaj
Without struggle, there is no progress
|
|
|
|
|
take a look at ILockBytes. i've used it with IStorage to create a memory-based file.
Software | Cleek
|
|
|
|
|
Thanks... I had no idea what he was talking about. 
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
In an application I'm making I need to use a menu to launch a modal dialog box. I seem to be struggling a bit with this task. How do I do it?!?!
Thanks!
Phillip
|
|
|
|
|
Hm, you handle the menu selection (add a handler with the Class Wizard if you use MSVC++ 6.0 ). In the handler, you declare a variable of the dialog class. Then, you call DoModal on the variable.
|
|
|
|
|
the menu part or the dialog part ?
did you create your dialog ? in the resources and in the code ( generated by the wizard )
did you add the menu item ( in the resources ) ?
did you create an handler for the menu item ? ( can be created from the wizard )
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
I've made the menu, made the handler for the menu item, and made the actual dialog box (and a corresponding class). I'm having trouble making an instance of the dialog class and calling DoModal for some reason. It's quite baffling, actually.
Phillip
|
|
|
|
|
#include "MyDialogClass.h"
//...
CXXX::OnSomething()
{
CMyDialogClass dialog;
dialog.DoModal();
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
