|
|
Thank to all! ON_CONTROL_RANGE is exactly what I was looking for.
Dave's PreTranslateMessage method worked for me too, but this looks cleaner for a simple job.
|
|
|
|
|
Is there something like std::_tstring?
Tx
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
No,
But I normally add, in my "stdafx.h"
typedef std::basic_string<tchar> _tstring;
typedef std::basic_stringstream<tchar> _tstringstream;
typedef std::basic_istringstream<tchar> _tistringstream;
typedef std::basic_ostringstream<tchar> _tostringstream;
|
|
|
|
|
Tx for the prompt reply. I will do something like this.
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
|
I should've think of that !
Thanks
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
Has anyone managed to get a tab control with vertical tabs (TCS_VERTICAL style) to work with an application on XP with an XP manifest?
The tabs are blank and generally wacked out. Am I missing something or is this a bug in XP?
Thanks for any info.
Regards, Larry Antram
Stardust Software
"I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones."
-- Albert Einstein
|
|
|
|
|
Nevermind, I found the following information on MSDN.
TCS_VERTICAL: Version 4.70. Tabs appear at the left side of the control, with tab text displayed vertically... [excerpt deleted] ... This style is not supported if you use ComCtl32.dll version 6.
IMO, that is extremely lame.
Regards, Larry Antram
Stardust Software
"I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones."
-- Albert Einstein
|
|
|
|
|
Larry Antram wrote:
"I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones."
-- Albert Einstein
Ya gotta love the man's sense of humor.
Jeremy L. Falcon<nobr>
Homepage : Sonork = 100.16311
"The height of your accomplishments will equal the depth of your convictions."
- William F. Scolavino
|
|
|
|
|
Hopefully it was humor.
Regards, Larry Antram
Stardust Software
"Why are we here? What is the purpose of life? A lot of people say it's meaningless. Nonsense. There's no use having a cosmos, no use having a universe, if you don't have an audience. The universe, needing an audience, created us. We are the meaning of life."
-- Ray Bradbury [Interview, April 18, 2002]
|
|
|
|
|
I have a security issue with a COM server I wrote. First let me describe the architecture:
This is a client/Server situation.
On the Client computer:
1. Run application (APP1).
2. APP1 passes request to dispatcher service on Server computer.
On the Server
Dispatcher Service (APP2) launches an intermediate application (APP3).
Intermediate calls .dll function.
.dll function performs CoCreateInstance on COMX.
COMX is implemented in APP3 as a local server.
COMX is registered with default configuration (DCOMCNFG)
The APP2 service is configured to logon as the system user.
When I test this on a Win2K system, all is well.
When I run on winNT4, I get access error when the .dll attempts CoCreateInstance.
I can work around the error by configuring the APP2 service to logon as a user account.
Unfortunately that will not work in our production environments.
I've messed around with DCOMCNFG to reconfigure the COMX server, but nothing seems to help, except changing the logon for the service.
I'm really stuck. Any ideas or suggestions will be appreciated.
Thanks for the help,
Bill
|
|
|
|
|
i have an MFC dialog application and i need to hide the main dialog on startup...
putting ShowWindow(SW_HIDE) in OnInitDialog() doesn't work and i need to be able to show the dialog again afterwards so i cant put it in OnPaint either.
Does anyone know how to do this?
Thanx
Kuniva
--------------------------------------------
|
|
|
|
|
For an MFC dialog app, the wizard puts these lines in the InitInsance of the app class.
CMyDialog dlg;
if (dlg.DoModal == IDOK)...
skip the do.Modal and your dialog won't be shown (or created either).
If you want it created, but not shown, you can call Create yourself. If you are eventually going to call DoModal, don't bother.
|
|
|
|
|
|
This method is by Joaquin.
Add TRUE boolean to your class and named it m_bFirstShowWindow .Then handle this event to your dialog class:
void CYourDlg::OnWindowPosChanging(WINDOWPOS* lpwndpos)
{
CDialog::OnWindowPosChanging(lpwndpos);
if(lpwndpos->flags&SWP_SHOWWINDOW)
{
if(m_bFirstShowWindow)
{
m_bFirstShowWindow=FALSE;
lpwndpos->flags&=~SWP_SHOWWINDOW;
}
}
}
Mazy
"If I go crazy then will you still
Call me Superman
If I’m alive and well, will you be
There holding my hand
I’ll keep you by my side with
My superhuman might
Kryptonite"Kryptonite-3 Doors Down
|
|
|
|
|
I spawn a modal dialog in am MDI CFormView project. Its a login screen. If I hit enter without any entries or even with, it vanishes!!!As you know the modal dlg form comes with an Ok and Cancel button.
I tried removing the OK button - no go.
I made the OK button not the default button (from properties) - still no luck.
I changed the ID of the OK button to a random name, overrode the ONOK function to be something like:
{
check data in login editboxes
store password in public variable
set int nret
EndDialog(nret)
return
}
return from DoModal() in spawning form and set text in box there to publicly accessible password from CLoginDialog.
This works if I click the okay button.
But if I press "enter" - everything is bypassed!
The login dialog vanishes and no info is transmitted!
Please let me know what I can do about this.
Thanks,
ns
Another issue:
In the initdialog of the CLoginDialog class
m_editbox.SetFocus();
is totally unresponsive!
|
|
|
|
|
this will fix it:
BOOL CMyDlg::PreTranslateMessage(MSG* pMsg)
{
if ((pMsg->message == WM_KEYDOWN))
{
if (pMsg->wParam == VK_RETURN)
{
return TRUE;
}
}
return CDialog::PreTranslateMessage(pMsg);
}
-c
Being just contaminates the void. --Robyn Hitchcock
|
|
|
|
|
Thank you.
Do I have to call this from anywhere. Do I just add it as a custom function or is it a windows message handler (selected from context menu on class), in which case it adds stuff in //afx areas of the cpp.
Is it like the UI_COMMAND_UPDATE handler that runs automagically when doc variables change?
Many thanks for responding on a pre-holiday eve.
ns
|
|
|
|
|
go to classwizard for your dialog and override PreTranslateMessage. it's a function override, not a message handler, so it will be in the top of the "messages" list. then put that little bit of code in the function CW generates for you.
-c
Being just contaminates the void. --Robyn Hitchcock
|
|
|
|
|
Gosh! Thanks so much! I truly appreciate it.
With all my struggles this afternoon, the best I could do and have the dialog not vanish with "enter" was rename the IDOK with ID_NOTOK, with no code in the click event for the newly named button. Then I put the rest of my stuff in the button called "Login" which dismisses appropriately with EndDialog. This was still going to leave me with a useless OK button which doesnt do anything anymore. So I was thinking of making it invisible when your life saving email arrived!
I'll try it in a few minutes.
Have a fun holiday!
Cheers,
ns
|
|
|
|
|
ns wrote:
Gosh! Thanks so much!
' any time.
-c
Being just contaminates the void. --Robyn Hitchcock
|
|
|
|
|
Works like a charm! Thank you so much!
One more hurdle overcome...
ns
|
|
|
|
|
I think you can also fix this by adding a cOK handler and returning false(or true... cant recall)
Anyways, I'm sure I didnt have to override pretranslate to do it. I can take a look at my old code if your interested...
|
|
|
|
|
I don't do MDI or form views, so perhaps this suggestion may be incorrect, but in general I assume it is probably better to simply override the virtual OnOK (for Enter) and OnCancel (for Esc) methods... and modify each to not call the base methods (which dismiss the dialog).
An easy way to do this with normal dialogs (without doing any real coding) is to put temporary IDOK and IDCANCEL buttons on your dialog... then double click each to add handlers via classwizard... then after that delete the two buttons from the dialog template... and finally comment out the // CDialog::OnOK(); or // CDialog::OnCancel(); calls.
Regards, Larry Antram
Stardust Software
"I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones."
-- Albert Einstein
|
|
|
|