|
Well it worked - Damn so simple
Now I can dynamically create/link any control without resorting to a frame class
directly to another - transparent to the Main dialog -- very useful
Derived a class from CToolbar toolbaradv
passed it the CWnd * pointer to ListboxAdv window -- m_Creator
Added handler
void toolBarAdv::OnNMClick(NMHDR *pNMHDR, LRESULT *pResult)
{
LPNMCLICK pNMClick = reinterpret_cast<LPNMCLICK>(pNMHDR);
m_Creator->SendMessage(10001,GetToolBarCtrl().GetHotItem());
*pResult = 0;
}
And caught the message in Derived listbox WndProc
All without having to touch the main parents message loop
And No "getting tied in knots trying to solve a problem that doesn't exist."
The problem has always been MS arrogance that "They have covered all the bases"
and not left room for expansion
A Class (or derived class) should be able to handle its messages pertaining to that class -- An options bar certainly qualifies -- you don't handle options local to the class externally --thats just bad widget design
This all got started because MS CListbox Doesn't allow access to resize its working area for the list
Example. A clistbox (no integral height),you add items and suddenly a scrollbar appears
(So a child scrollbar was Dynamically added and the listbox internals were recalculated to accomodate it --A variant of what I'm trying to do - Add a needed child) -- but try to find/modify the bloody routines that recalculate.
Basically I'm doing the same thing - Simply add a toolbar pertaining to options for the new derived listbox --Though not actually "in" but on in this case
PS in my dialogs I have 10 of these Listboxes -- think of the handling in main dialog message loop
Well nap time
|
|
|
|
|
I have a stack. When compiled with O3 it crashes. Works fine when compiled with -g . Any idea what is issue n how to debug it.
modified 5-Feb-12 13:35pm.
|
|
|
|
|
What are you talking about? compiler options, linker options? Clarify your question, it's not clear.
|
|
|
|
|
Compiler does ugly nice tricks when optimization is ON (on the other hand the debug build may hide some errors - e.g. it may initialize data you forgot to).
However we cannot help you more, without seeing your code.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: it may initialize data you forgot to
I hate it when it does that... 
|
|
|
|
|
Not unusual. The bare minimum you should provide is a call stack and the source code around the actual code that blows up (if possible).
Steve
|
|
|
|
|
Hi,
I don't know if i am in the right forum as my problem seems to be unserstanding of TCP/IP as opposed to MFC
I am using CAsynSocket class to communicate with a server running on a MainFrame
I have my CAsyncSocket object wrapped inside a CWinThread object
In the CWinthread::Initinstance I do CAsyncScoket::Create get a 1 return code to
indicate success
On the MainFrame end I have a Select command looking for connections from the client
Stepping thru the code on Visual Studio after the CAsynSocket::connect I get
a 0 return code the Getsystem error is 10035 (connection not complete)
The (Server) however on the mainFrame detects a connection and issues a subsequent
Accept then is waitting to read information from Windows MFC client
My problem is that the Windows MFC Client CASyncsocket::OnConnect callback function is
never invoked to complete the connection from the client
Any help of someone pointing me to where I can further debug this would be appreciated
Thanks
|
|
|
|
|
The thing I want to point out(just a guess) is that may be because of debugging process your connection is getting lost in the middle. You should check. Try to skip few parts during debugging and check if it returns the proper value
|
|
|
|
|
On the client side... why don't you try using a synchronous socket first? The biggest difference is that all the calls will block until they return but the coding should be simpler... and the asynch and synch sockets are essentially the same internally (within the framework). If the synchronous socket doesn't work, maybe you're doing something else wrong, hard to tell without any code. There could be a number of things wrong.
|
|
|
|
|
Hi,
I am assuming you are refering to CSocket class since it is derived from CAsynSocket
I can call CSocket::connect
it will block unitil connection is complete
|
|
|
|
|
Yeah, that's the difference between the two, one is synchronous and the other is asynchronous.
|
|
|
|
|
Okay
it worked on Create (port,SOCK_STREAM,NULL)
since these options are not on the CSocket version of
FD_READ|FD_WRITE|FD_CONNECT|FD_CLOSE|FD_OOB|FD_ACCEPT I assume they are in effect
The Connect got a "1" so I assumeed it worked
All the overidlable OnSend OnRecieve are in effect except I assume OnConnect
I have to do further testing However it is late here in East Coast US
If I run into another problem I'll start another post
thank you
|
|
|
|
|
How can we determine the phisycal drive where is installed the running operating sistem (windows)?
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
GetWindowsDirectory()[^] should help you. It will give you the whole path, but you can find the drive from the path.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
GetWindowsDirectory() returns a path like X:\win64. I need to determine what
\\.\PhisycalDriveN hosts the X: partition. Any solution?
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
May be this MSDN example [^] is helpful.
|
|
|
|
|
I write an app for media erasure.
It displays via DISK_GEOMETRY and Device IoControl PhisycalDriveX.
It is important not to try erasure on the phisycal device that holds the OS. So, I need to see if the OS that runs is located on a phisycal drive that I intend to erase.
Probably is better to skip that device.
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
There is no API function returning the physical devive. You must use GetWindowsDirectory() and then determine the device for the drive letter.
|
|
|
|
|
... and how to determine the device for the drive letter? 
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
Use the QueryDosDevice[^] function to get the physical device name from the drive name.
Make sure the drive name does not contain the trailing '\' (e.g: use "c:" instead of "c:\\")
This will give you something like \Device\HardDisk0 or whatever is relevant to your machine.
I hope this helps
"It was when I found out I could make mistakes that I knew I was on to something."
-Ornette Coleman
"Philosophy is a study that lets us be unhappy more intelligently."
-Anon.
|
|
|
|
|
See the link from my previous post. It does not contain a ready-to-use solution, but contains enough information to do it yourself.
|
|
|
|
|
You can use the ExpandEnvironmentStrings API with the %SYSTEMDRIVE% environment variable.
|
|
|
|
|
|
I want to set a window position below on listctrl selected item :
BOOL CMyDlg::OnInitDialog()
{
CDialog::OnInitDialog();
SetIcon(m_hIcon, FALSE);
SetWindowPos(NULL, m_nX, m_nY, 0, 0, SWP_NOSIZE | SWP_NOZORDER);
return TRUE; }
and from an form with a list-control, I want to show above dialog right below of selected list-control item :
int nItem = 0;
POSITION pos = m_List.GetFirstSelectedItemPosition();
if(pos)nItem = m_List.GetNextSelectedItem(pos);
CRect rect;
CPoint point;
CMyDlg dlg;
m_List.GetWindowRect(rect);
m_List.GetItemPosition(nItem,&point);
ClientToScreen(&point);
dlg.m_nX = rect.left;
dlg.m_nY = rect.top + point.y;
dlg.DoModal();
still, the CMyDlg dialog does not position right below of selected listcontrol item ...
I didn't find an list-control method to help me out ... can you give me a little ideea ?
Thank you.
|
|
|
|
|
Not sure this will work, but try:
m_List.ClientToScreen(&point);
dlg.m_nX = point.x;
dlg.m_nY = point.y + 10;
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
