I joined the Vienna's Boys Choir when I was 8 and later on studied conducting & composing. I'm playing the piano for more than 20 years now. I'm deeply involved into recording , electronic-instruments stuff and musically directing shows and musicals. I just started to programm because my dream of a perfect midi-masterkeyboard-software for keyboarders, studio-cracks or threatre-technicians never came true. No company ever did the ultimative thing, yet. I will do it...;) Manfred --- Programming is knowing...

If it doesn't bother you that the standard buttons of a property sheet are always there use it. If you do - like I do in my dialog-based-application now - you have to use the CTabCtrl. The difference is that you have to create a dialog for each rider of the tab. The tab itself is just a container. So by selecting the riders of a tab you just call up a user-defined dialog.

• Put a tab (like IDC_TAB1) in your dialog (CMyDialog) with the dialog editor

• Open the Class-Wizard and attach a CTabCtrl-Member-Variable (like MyTabCtrl) to your tab-resource (IDC_TAB1)

• Then you have to tell your tab about the number of riders and their names (with a TC_ITEM structure)

  BOOL CMyDialog::OnInitDialog()
  {
  CDialog::OnInitDialog();

  TC_ITEM TabCtrlItem;
  TabCtrlItem.mask = TCIF_TEXT;

  TabCtrlItem.pszText = "Name of the Rider 1"
  MyTabCtrl.InsertItem(0, &TabCtrlItem);

  TabCtrlItem.pszText = "Name of the Rider 2"
  MyTabCtrl.InsertItem(1, &TabCtrlItem);

  TabCtrlItem.pszText = "Name of the Rider 3"
  MyTabCtrl.InsertItem(2, &TabCtrlItem);
  }

• Derive a dialog-class (like CMyFirstRiderDialog) from CDialog

• You should create another dialog resource (like IDD_MY_FIRST_RIDER) that represents the content of your rider

• In the function void CMyDialog::OnShowWindow(BOOL bShow, UINT nStatus)
  you'll have to create your rider-dialog.

  void CMyDialog::OnShowWindow(BOOL bShow, UINT nStatus)
  {
  CDialog::OnShowWindow(bShow, nStatus)

  if(bShow)
  {
  MyFirstRiderDialog->Create(IDD_MY_FIRST_RIDER, MyTabCtrl.GetActiveWindow());
  MyFirstRiderDialog->ShowWindow(SW_SHOW);
  }
  }

• In the Message Handler of your TCN_SELCHANGE and TCN_SELCHANGING message of your IDC_TAB1 object
  you have to destroy your MyFirstRiderDialog and create the dialog dedicated to your other tabs.

  void MyDialog::OnSelchangingZone(NMHDR* pNMHDR, LRESULT* pResult)
  {
  switch(MyTabCtrl.GetCurSelection())
  {
  case 0:
  CMyFirstRiderDialog->DestroyWindow();
  break;

  case 1:
  CMySecondRiderDialog->DestroyWindow();
  break;

  default:
  ASSERT(0);
  break:
  }
  }

  void MyDialog::OnSelchangZone(NMHDR* pNMHDR, LRESULT* pResult)
  {
  switch(MyTabCtrl.GetCurSelection())
  {
  ca

Just put up a timer

SetTimer(1, 7000, NULL); // for 7000ms == 7sec

and when WM_TIMER (after 7sec) is called by the framework, just set your

void MyDialog::OnTimer(UINT nIDEvent)
{
if(nIDEvent == 1)
{
KillTimer(1);
MyDlg.EndDialog(IDOK);
}
}

I guess, that's what you wanted to know... Manfred --- Programming is knowing...

I followed your advice, Chris - and went to your CodeGuru link. http://codeguru.earthweb.com/debug/ReleaseMode.shtml There was one comment by Kelly Beyer: 'Incorrect Message Map Function Signatures' which referred to a MSDN-KnowledgeBase article. http://support.microsoft.com/support/kb/articles/Q195/0/32.ASP So I changed the handler macro of my User-defined message from

afx_msg void OnMyMessage(void);

to

afx_msg LRESULT OnMyMessage(WPARAM, LPARAM);

And my handler-function from

void MyDialog::OnMyMessage(void);

to

LRESULT MyDialog::OnMyMessage(WPARAM, LPARAM);

And now it works. In all my books showing how to write User-defined messages it is done the wrong way. No explanation that the signatures have to be exactly like the ones above. They all used 'void' instead - and as, when being a beginner, you seldomly switch to release-mode you never realize that there is a little bug in your application. And when you do it once than you'll never find out when this bug silently came into your app. Though it's hard to put the blame on a User-defined message that worked for months in DEBUG-MODE. Believe me: You would take everything else under consideration before this... But at least I think it is a very bad behaviour that the compilor doesn't give you at least a warning when working in DEBUG-MODE (I'm only working in 'Warning-Level 4'). I would never have found the bug in my app without that articles on the net. There is one little question still bugging me as I got a little paranoid now. Do you think that this is the real solution to my problem or is it just a temporary workaround that is hiding another surprise for me now for the future??? Does it sound like 'there must be something else' to you ??? Thanks again for your help - this time a hit, not only a try... Manfred --- Programming is knowing...(and having better friends than the MicroSofties)

Thanks Chris - it's once again YOU to help me (try to) out of a problem. OnPaint() is working now as it is supposed to... Also thanks to all the other Gurus: 'Funky' Erik (Funkenbusch) and Lauren (I like the colours of your homepage)... The unhandled exception 0x00000005:Access Violation occurs in a WIN callback-function. When I open some MIDI-Input with

midiInOpen(&hMidiIn, CurInDevice, (DWORD)MyCallback, NULL, CALLBACK_FUNCTION);

The 3rd parameter is the address of a callback-function which is called by the Midi-Device-Driver everytime a MIDI-Event has arrived its input. The callback works as follows:

void CALLBACK MyCallback(HMIDIIN hMidiIn, UINT wMsg, DWORD dwInstance, DWORD dwParam1, DWORD dwParam2)
{

int iResult;

switch(wMsg)
{

case MIM_DATA:
{
iResult = Zones->PostMessage(WM_MIDIEVENT); //Zones is the Main-Window of my Dialog-based App
ASSERT(iResult);
break;
}

case MIM_MOREDATA: break;
case MIM_OPEN: break;
case MIM_CLOSE: break;

default:
ASSERT(0);

}

So the callback only posts a userdefined message

#define WM_MIDIEVENT WM_USER+100

to my Dialog. The MessageMapEntry

ON_MESSAGE(WM_MIDIEVENT, OnMidiEvent)

is for now just a stub - doing nothing...

void CZones::OnMidiEvent()
{
}

When the first MIDI-Event arrives everything works fine, but as soon as the second event drops in I may not move the mouse over the System-Menu or click the Dialog or move over a checkbox in the dialog. As long as I don't move the mouse I can play as many notes as I want... BTW: When the Dialog is minimized everything works flawlessly too. But I only have to right-click into the task-bar.....EHHHHHH No context-menu for maximizing or closing - just my unhandled exception 0x00000005:ACCESS-VIOLATION Any Ideas on that ? The exception appears on two machines exactly at the same address. In DEBUG-MODE everything works brilliant, no latency (MIDI-delays) no MIDI-drones (sounding till you shut down your system) - no really professional... Manfred --- Programming is knowing...

Does anybody know if there is a common or wellknown behaviour why an MFC-Application works flawlessly in DEBUG-Mode and suddenly when compiled in RELEASE-Mode throws the unhandled exception 0x00000005:Access violation??? Manfred --- Programming is knowing...

Quick answer... I've defined every key of my piano-keyboard as a region. That means 88 keys(regions). 52 white keys and 36 black keys. - CRgn-Array as a Member of my Dialog CRgn KeyRegion[88]; - In the constructor of my dialog I create them all KeyRegion[KeyNumber].CreateRectRgn(); - so I guess the array gets automatically deleted when destroying the dialog - should not be leaking... - In my function OnPaintKeyboard() I paint all my 88 keys CClientDC dc(this); CBrush BlackBrush; BlackBrush.CreateSolidBrush(RGB(0,0,0)); CBrush WhiteBrush; WhiteBrush.CreateSolidBrush(RGB(255,255,255)); - With... dc.PaintRgn(&KeyRegion[KeyNumber]); - I can paint my region in the color of the previous selected Brush-Object e.g. dc.SelectObject(&BlackBrush); That looks good to me... - And to you ??? I have a second function OnPaintKey() that paints a single key only - not the whole keyboard. 1 - One Question is wherefrom should I call my OnPaintKeyboard() function so that the whole keyboard gets painted when the dialog gets visible on screen? 2 - Second Question is wherefrom should I call my OnPaintKeyboard() function so that the whole keyboard gets correctly redrawn when necessary?(Overlaping windows or Moving and removing out of the visible screen...) 3 - Third Question: Where can I use my OnPaintKey() function (for a single key!!!) so that not every key has to be redrawn when only the color of one key changes ? Manfred --- Programming is knowing...

OKI For now I selected the CRgn as my object of desire because 1 - I want to paint a Piano-Keyboard onto the screen in my Dialog 2 - When comparing OnLButtonDown(nFlags, point) with PtInRegion(point) I can easily find and repaint single keys. 3 - Regions don't flicker - not in BLUE, not in BLACK not in any color Is there any disadvantage of using Regions ? Thanks for your help Manfred --- Programming is knowing...

To your first: Why should I use CPaintDC instead of CClientCD ? I'm having a dialog-based application and only want to paint a Piano-keyboard onto the screen. This I will do once when entering the Dialog. At runtime I will change the colors of single keys so no need for redrawing the whole keyboard - only single keys... To your second: I guess with 'deselecting' you mean 'deleting' my pens and brushes. Because deselecting happens everytime I select a new Object with the SelectObject() function. So do I get it right now ??? 1 - Every DC has at least one original PEN, BRUSH, FONT, BITMAP and RGN. 2 - When creating a new e.g. PEN/BRUSH I have to store the original PEN/BRUSH with CPen* pOriginalPen = dc.SelectObject(&NewPen); CBrush* pOriginalBrush = dc.SelectObject(&NewBrush); 3 - and give it back to the DC at the end of the function. dc.SelectObject(pOriginalPen); dc.SelectObject(pOriginalBrush); 4 - Every pen, region, font, bitmap or brush created with e.g. BlackPen.CreatePen(PS_SOLID, 1, RGB(0, 0, 0)); WhitePen.CreatePen(PS_SOLID, 1, RGB(255, 255, 255)); BlackBrush.CreateSolidBrush(RGB(0, 0, 0); WhiteBrush.CreateSolidBrush(RGB(255, 255, 255); 5 - must explicitely be deleted with (respectively AFTER having given my OriginalObjects back to the DC) BlackPen.DeleteObject(); WhitePen.DeleteObject(); BlackBrush.DeleteObject(); WhiteBrush.DeleteObject(); 6 - This means the objects are not deleted automatically at the end of the function. I wonder why this DC related things are relatively difficult in comparison with other parts of the MFC. I went through all the DC-related SDK and MSDN stuff and through several books but this is realy not explained rather clearly in any place. Hope that someone can get me out of this only-one part I do not realy get in my brain. Thanks Manfred --- Programming is knowing... (should be ;-))

// // This is, what I have actually written into my dialog's OnPaint()-function: // CClientDC dc(this); CPen WhitePen; CPen BlackPen; CBrush BlackBrush; WhitePen.CreatePen(PS_SOLID, 1, RGB(255,255,255)); BlackPen.CreatePen(PS_SOLID, 1, RGB(0,0,0)); BlackBrush.CreateSolidBrush(RGB(0,0,0)); CPen* pOriginalPen = dc.SelectObject(&BlackPen); dc.Rectangle(24, 10, 80, 30); dc.SelectObject(&BlackBrush); dc.Rectangle(24, 10, 80, 30); // // Instead of the last two lines I've also tried it with: // dc.FillSolidRectangle(24, 10, 80, 30 RGB(0,0,0)); // // How can I get rid of this flickering of the black rectangle in my dialog??? :confused: // // // Thanks in adv. // // // Manfred // --- Programming is knowing...

Listbox Notification works only if a list item has been clicked or double-clicked... Or show me exactly what you mean...!?! :confused: Manfred --- Programming is knowing...

Does anybody know how to retrieve a WIN-message that indicates the scrollbar of a Listbox having been scrolled up or down? I have a modeless dialog with 6 listboxes (side by side) that get the V-Scrollbar automatically when there are more Items to display than the LBs can show at once. All lists do always have the same lenght due to the behaviour of my data. What I want is to keep the LBs synchron - I mean that the TOPINDEX is the same in all my boxes. Even when I move the scrollbar I wanna keep them in sync. That works fine with the LBN_SELCHANGE for every box: void CMyClass::OnSelchangeList01() { int iResult; iResult = m_List01.GetCurSel(); m_List01.SetCurSel(iResult); m_List02.SetCurSel(iResult); m_List03.SetCurSel(iResult); m_List04.SetCurSel(iResult); m_List05.SetCurSel(iResult); m_List06.SetCurSel(iResult); iResult = m_List01.GetTopIndex(); m_List01.SetTopIndex(); m_List02.SetTopIndex(); m_List03.SetTopIndex(); m_List04.SetTopIndex(); m_List05.SetTopIndex(); m_List06.SetTopIndex(); } The same I do for OnSelchangeList02(); OnSelchangeList03(); OnSelchangeList04(); OnSelchangeList05(); OnSelchangeList06(); I can select whatever I want in whatever LB - with the mouse or the arrow-keys. The TopIndex of every LB is the same and the selected items (highlighted) appear side by side. So far so good - ONLY after moving the vertical scrollbar the LBs are out of sync because I cannot get any message of the scrollbar showing me that the visual state of the LB has changed and though giving me the possibility to use the SetTopIndex()-function like above in the LBN_SELCHANGE message handler of my LBs... I tried it with CWnd::OnVScroll() but I couldn't find a way to retrieve a notification from my Listbox-scrollbars out of this function... All those nice SB_BOTTOM, SB_TOP, SB_THUMBTRACK - and I cannot access them...... So any Ideas out there...? Manfred --- Programming is knowing...

In my dialog-based application I use some other (modeless) dialogs-boxes that have the same size than my parent and aligning exactly centered in my frame-dialog when appearing. ( created with MyDialog->Create() ). For this behavior I had to use the style 'Child' in the dialog-editor. For some reason I need one dialog to appear MODAL and so I created the dialog with MyDialog->DoModal(). If I leave the style 'Child' the dialog totally locks the application when appearing. So I changed the style to 'Popup'... Now it worked ALMOST like a charm. One problem left: When I open the modal dialog it is exactly aligned relative to its parent window. When I move the parent dialog but still visible on the screen and then open the modal dialog it also aligns correctly. But from the moment I move my parent out of the screen so that e.g. only a part of my parent is visible the modal dialog appears fully visible docked to the edge of the screen but not aligned to the parent anymore. Is there any workaround or setting that the modal dialog appears aligned to my parent even if I move my parent out of the visible part of the screen. As I created all my dialogs in the application with thin borders and no title-bar you do never realize that with every view-change a new dialog is created. Only in the above mentioned situation the thin boarderd-modal-dialog stands alone on the screen - looking ugly... Any Ideas on that ? Manfred --- 'Programming is knowing...'

And how can I enumerate through all active windows? Any function() available?:confused: Manfred

Does anybody know how I can force my MFC-Dialogbased-Application to be opened only once. No second instance should be possible. I tried it with a flag BOOL MyInstance = FALSE; in the InitApplication() - and in the InitInstance() I wrote if(!MyInstance) { MyInstance = TRUE; CZones dlg; m_pMainWnd = &dlg; dlg.DoModal(); } I thought that InitApplication() is called only once and every further Instance is just calling InitInstance(). But it looks like every Instance is also calling InitApplication()... Any Ideas ? Manfred

e.g. In my MIDI-Callback function (like your Device-Driver-Message) I post a Message to the Message-Queue of the window that should receive the message with: PostMessage(WM_MYMESSAGE); You have to: #define WM_USER + 100 WM_MYMESSAGE (in your Resource.h) afx_msg void OnMyMessage(); (in the destination window's MessageMap MyClass.h) ON_MESSAGE(WM_MYMESSAGE, OnMyMessage) (in the destination window's MessageMap MyClass.cpp) before posting the Message. You have to do it manually (VC++5) for the Class-Wizard does not support User-Messages to be created... In OnMyMessage() which is directly called by your driver-message you can write your Code now. Hope that helps Manfred