|
I think in 95/98/Me, you have to monkey with the WIN.INI file to get the info you need. Try something like this:
TCHAR buffer[MAX_PATH];
::GetProfileString("Windows", "device", "", buffer, MAX_PATH);
(Look up GetProfileString on MSDN for more info.)
The printer info should be in that buffer, although I think it also contains some additional stuff (like the port name) so you may have to parse it a little.
Hope this gets you on the right track.
Even a broken clock is right twice a day.
|
|
|
|
|
Look up the ::PrintDlg Win 32 API Function. There is a flag you can set to retrieve the default information. If you are using MFC, CPrintDlg offers the same functionality. You can get the information without displaying the dialog in either case.
|
|
|
|
|
I need to avoid that a dialog get the focus when it's called.
How can I make this ??
[]'s
Cris.
|
|
|
|
|
do not pass WM_SETFOCUS to default window process.
i.e. in MFC
MyCls::OnSetFocus(*)
{
//cancel this line
//CWnd::OnSetFocus(*);
}
includeh10
|
|
|
|
|
In the ClassWizard don't have the WM_SETFOCUS event. But I did write the event and it's not trigged. Do you know why ??
[]'s
|
|
|
|
|
goto last page, select window, it will appear.
includeh10
|
|
|
|
|
What ??
Last page ??
The WM_SETFOCUS don't appear int the MCF Class Wizard dialg.
[]'s
|
|
|
|
|
What ??
Last page ??
Last page of Class wizard!
if still don't understand, let me know with no hesitate!
includeh10
|
|
|
|
|
Ok, thanks for your help ...
[]'s
Cris.
|
|
|
|
|
'ello,
I have a problem with a CListView derived class, it refuses to show the Header control when in report view. I've tried a few things including commenting out all except
GetListCtrl().MofifyStyle(LVS_TYPEMASK,LVS_REPORT);<br />
GetListCtrl().InsertColumn(0,"Test",LVCFMT_LEFT,100);
in OnInitalUpdate().
The app is a appwizard produced SDI app with the "Windows Explorer" option enabled" and has the Listview view options buttons on the toolbar, the selected mode shows as the Details mode when the app starts but the CHeaderCtrl() is never created ( GetListCtrl()->GetHeaderCtrl() returns NULL ).
Another appwizard produced app with all the same modes works ok, anyone else as confused as me? 
[EDIT]
Never mInd i forgot to delete the defualt (empty) implmentation of OnStyleChanged [/EDIT]
Richard Green
|
|
|
|
|
Does anyone knows how can i capture mouse movements from the driver of the mouse and not by capturing WM_MOUSEMOVE.
I need somethig like "LowLevelMouseProc" for all windows and not only for 2000 and XP.
Thanks.
|
|
|
|
|
::GetCursorPos
Back to real work : D-23.
|
|
|
|
|
Is there any reason why i should not use RegisterWindowMessage() to define messages specific to my applications (i.e. not used for inter-process communication). MSDN says that I should use WM_USER + i to do this, and not RegisterWindowMessage(), but having read several discussions on the topic I am not sure that I see why...
Any ideas?
Alex
|
|
|
|
|
In fact, RegisterWindowMessage() is the most desireable version of a private message.
(WM_USER+const being the least favorable, WM_APP+const intermediate).
You just have to remember to make your handler-function HRESULT name(WPARAM, LPARAM) and use the ON_REGISTRED_MESSAGE() macro.
|
|
|
|
|
jhwurmbach wrote:
In fact, RegisterWindowMessage() is the most desireable version of a private message.
Is that because they're guaranteed to be unique to the string used to identify them and therefore you get less potential conflicts?
Are you saying that there is no situation where a RegisterWindowsMessage is less preferable to a WM_USER + i one?
Cheers, Alex.
|
|
|
|
|
You should never use WM_USER+i, because some i are already used by some (newer) windows controls. You get almost undebuggable errors when you are reacting to messages that are not meant for you.
Use WM_APP+i, this is guaranteed not to be used by Windows internally.
You then only have conflicts with controls from other sources (commertial or third party).
Use of RegisterWindowsMessage() avoids all this at no cost.
No, I cant think of a situation where WM_USER is more preferable than RegisterWindowsMessage().
|
|
|
|
|
If you are making your own control, WM_USER+x is fine.
However, for application level messages, I have to agree that RWM is better.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
You should use RegisterWindowMessage only. Read this[^] for details!
Best regards,
Alexandru Savescu
|
|
|
|
|
Alexandru Savescu wrote:
You should use RegisterWindowMessage only. Read this[^] for details!
This (and that on message management) was one of the articles I was referring to in my originaly post. I was wondering why MSDN says that you should only use RegisterWindowsMessage() for inter-process messages and WM_USER + i for the others.
I suppose it's just like a lot of the other bits in MSDN - looks absolutely fine until you talk to other people about it...;)
|
|
|
|
|
What I need to do is compare a series of strings (actually filenames) and find potential duplicates. The strings, however, are unlikely to contain literal duplicates so what I need to do is find similar strings. Has anyone ever had experience of this before?
Cheers
James
|
|
|
|
|
Yes, this is a common need in credit applications (find names mistyped). In your case, I suggest the Levenshtein String (or Edit) Distance algorithm for this. You can find tons of implementations in C++ on google.
lazy isn't my middle name.. its my first.. people just keep calling me Mel cause that's what they put on my drivers license. - Mel Feik
|
|
|
|
|
Thanks for that Daniel. I took a look at it and that solves part of my problem. The other part of the problem is that I need to find duplicates based on whether a string has some elements of another.For example, I would want to match the following filenames
c:\Music\Albums\Vines\01 - Highly Evolved.mp3
c:\Music\Singles\The Vines - Highly Evolved.mp3
f:\Stuff\Vines - Highly Evolved.wma
Do you know if there is a standard way to do this? I don't think there is but I just wanted to make sure.
Cheers
James
|
|
|
|
|
If you are really into informatics as a science, maybe some algorithms from bioinformatics can help you. Finding substring in one another and computing similarity-distance is quite common in DNA-sequence handling.
You will find more stuff about that in the net than you are able to read in the entire rest of your life.
|
|
|
|
|
Hi:
I meet a problem, it has puzzled me for a long time. I create a COM dll which support MFC, several
methods was exposured. The implement code of two methods was shown as follow:
STDMETHODIMP CMyComObj::OnConfiguration(long iReserved, BOOL *pbSuccess)<br />
{<br />
AFX_MANAGE_STATE(AfxGetStaticModuleState())<br />
<br />
CMyCfgDlg dlg;<br />
int rtn = dlg.DoModal();<br />
*pbSuccess = (rtn == IDOK) ? TRUE : FALSE;<br />
return S_OK;<br />
}<br />
<br />
STDMETHODIMP CMyComObj::ShowUIFace(long hParentWnd)<br />
{<br />
AFX_MANAGE_STATE(AfxGetStaticModuleState())<br />
<br />
pdlg = new CMyUIDlg();<br />
if(pdlg != NULL)<br />
{<br />
pdlg->Create(ID_MYUIDLG,CWnd::Fromhandle((HWND)hParentWnd));
}<br />
*pbSuccess = (rtn == IDOK) ? TRUE : FALSE;<br />
return S_OK;<br />
}<br />
The problem is in the first method call, the dialog shown normal and I can use TAB switch focus from
one control to another control. When I use the second method call, the dialog shown normal but can't
use TAB to switch focus(It does not take effect). The reason is virtual function PreTranslateMessage
was not be processed, What's wrong? Please help me!!!
I am seeking...
For what?
Why did you ask me for what? I don't know!
|
|
|
|
|
nothing wrong.
in MFC, PreTranslateMessage is only function which handles all of messages (similar to windows in Win32).
for other function (i.e. WindowProcess), MFC filters (bad design, i think) and adds many messages.
typically, it filters TAB, arrow key: up,left,right,down.
if TAB doesn't work, normally arrow keys don't work eithr
includeh10
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
