|
Hi,
I am developing an application that shows the current file path in an address bar. I am using a Cedit control to display the filename, I do not use a CComboBox as I do not want to keep a history list.
I would like to show an icon next to the full path name, just like explorer does.
Is it possible to display an icon in a CEdit control. Should I use custom drawing?
Please help,
Woody
|
|
|
|
|
Woody Green wrote:
Should I use custom drawing?
Yep!
Max.
|
|
|
|
|
If you want the icon to really be in the edit control, then you're going to have to do owner draw.
But wouldn't it be simpler to have a small static control next to the edit one, and display the icon in
that? If you had a button rather than a static control, you could add functionality (e.g. change associations)
Iain.
|
|
|
|
|
Yes, if you want to put an icon inside a CEdit you must draw yourself the control...
But I think it would be easier to use a CListCtrl and editing labels if you need it, if you need only visualization, it would become easier.
regards
|
|
|
|
|
Hi Joan,
I did as you suggested and used a CListCtrl, works perfect! It's just what I needed and indeed much easier.
 THANKS!
|
|
|
|
|
i use the fucntion:
"WINOLEAPI OleCreateLinkToFile(...)" to create some file links(show the file icons just like in CListCtrl)in my CRichEditCtrl Control,The result is successful,But it takes me about 20 second(Celeron 1G + 256M SDRAM).I want to known some more quick method to do.Any help is appreciated.thanks!
C/C++ code fans
|
|
|
|
|
I'm using STL vector containing some pointers. The only changes i make to it is to add values using push_back. I also keep an iterator which starts from the beginning and only grows by ++, being checked not to pass the end.
The problem, while debugging: sometimes when i try to access the iterator, the application is blocking on that line.
Could the iterator become invalid because of the vector growing?
rechi
|
|
|
|
|
Bogdan Rechi wrote:
Could the iterator become invalid because of the vector growing?
I sure wouldn't think so, are you using something like this:
vector<int*> vect;
vector<int*>::iterator iter;
int a, b, c, d = 1;
vect.push_back(&a);
vect.push_back(&b);
vect.push_back(&c);
vect.push_back(&d);
for(iter = vect.begin();iter != vect.end(); iter++)
cout << *iter << endl;
Nick Parker
May your glass be ever full.
May the roof over your head be always strong.
And may you be in heaven half an hour before the devil knows you’re dead. - Irish Blessing
|
|
|
|
|
Nick Parker wrote:
are you using something like this
Yes, something equivalent.
The difference: int * is a MyStruct * and cout<< *iter; is an (*iter)->m_member access.
What's wrong? 
rechi
|
|
|
|
|
Bogdan Rechi wrote:
What's wrong?
This works for me:
struct MyStruct
{
int data;
};
void main()
{
vector<MyStruct*> vect;
vector<MyStruct*>::iterator iter;
MyStruct a, b, c, d;
a.data = 1;
b.data = 2;
c.data = 3;
d.data = 4;
vect.push_back(&a);
vect.push_back(&b);
vect.push_back(&c);
vect.push_back(&d);
for(iter = vect.begin();iter != vect.end(); iter++)
cout << (*iter)->data << endl;
}
Nick Parker
May your glass be ever full.
May the roof over your head be always strong.
And may you be in heaven half an hour before the devil knows you’re dead. - Irish Blessing
|
|
|
|
|
Solved!
Sorry, it was not quite equivalent. It's more like this:
vector<int*> vect;
vector<int*>::iterator iter;
int a, b, c, d = 1;
vect.push_back(&a);
iter = vect.begin();
vect.push_back(&b);
vect.push_back(&c);
vect.push_back(&d);
for(;iter != vect.end(); iter++)
cout << *iter << endl; The iterator becomes invalid because of the vector growing.
Thank you!
rechi
|
|
|
|
|
Bogdan Rechi wrote:
I also keep an iterator which starts from the beginning and only grows by ++, being checked not to pass the end.
What do you mean by that ? I think the iterator is simply not valid.
Max.
|
|
|
|
|
Take a look at the thread above. Indeed, the iterator was not valid.
rechi
|
|
|
|
|
How to get the HINSTANCE of a dll?
Is there a way to get the HINSTANCE from a dll,
without saving the HINSTANCE from the DllMain or
calling GetModuleHandle("DLLName")?
I want to use the HINSTANCE in a COM-Object, thus
its not elegant to hand over it from the DllMain.
Otherwise the dll should exists with different names,
witch make it inconvenient to use a filename in the code.
Thanks
Juergen
|
|
|
|
|
I have a trouble with a CButton derived class.
The code is like the following:
class CMyButton : public CButton
{
....
}
CMyButton::SetColor(...)
{
...
Invalidate();
...
}
CMyButton::OnPaint()
{
...
CPaintDC dc(this);
...
}
------------------------------------
First, I created a CDialog derived class with a "Group Box" control inside and a DDX variable associated called MyGroup. I changed the type of MyGroup variable in CMyButton. Calling the SetColor() method of MyGroup, the Invalidate() causes the OnPaint() execution and the control is successfully drawn.
Then I changed the CDialog derived class with a CDialogBar derived class.
I have the following problems:
1) The Invalidate() method doesn't causes the execution of the OnPaint();
2) If I change the Invalidate() statement with the direct call of OnPaint(), the execution of the statement "CPaintDC dc(this)" fires the following assertion of "void CWnd::AssertValid()"
ASSERT((CWnd*)p == this);
Can you help me?
Thank you.
|
|
|
|
|
Is here any API to work with WinPopup massages.
Thank you
viliam
|
|
|
|
|
check out mailslot API
I am seeking...
For what?
Why did you ask me for what? I don't know!
|
|
|
|
|
If anyone codes managment of OOB data on a windows socket (winsock2), I would be really grateful if he/she could help.
I try to catch an OOB signal, and then remove data which are before the OOB mark, in a socket configured as SO_OOBINLINE.
TIA,
K.
Ohé Partisans, Ouvriers et Paysans
C'est l'alarme!
Le Chant des Partisans
|
|
|
|
|
Using common controls like e.g. the date-time picker enhances the look-and-feel of your application, but also seems to introduce an annoying language-problem.
Even if our application is running in e.g. German or Italian, the strings in the common control (and common dialogs) remain in English.
From the MSDN documentation I found that there is a function InitMUILanguage than you can use to change the language of common controls. I used it as follows:
{
HMODULE CommonControlDll = LoadLibrary("comctl32.dll");
if (CommonControlDll)
{
void (*InitMUILanguageFunction)(LANGID uiLang) = (void (*)(LANGID))GetProcAddress(CommonControlDll, "InitMUILanguage");
if (InitMUILanguageFunction) InitMUILanguageFunction (LANG_ITALIAN);
}
}
But apparently, it does not seem to work.
Notice that I had to dynamically load comctl32.dll and find the function in the DLL. Calling it directly in my application results in an unresolved external, hence this trick.
Does anybody use this function to set the language of common controls?
Does this only work on certain 'flavours' of Windows 2000 (won't probably work on NT4) ?
So far I found out that the language of the common controls only reacts on the language selected in the control panel (the locale), but not consistently. E.g. setting the language to Italian only translates the names of the months in Outlook, not the button 'Today'.
For the common dialogs (e.g. printer configuration) the situation seems to be even much worse. Setting the language to Italian only translates 'Properties' to 'Proprieta' and 'Cancel' to 'Annula', but all the rest is still in English.
What is the correct way to handle this ?
Enjoy life, this is not a rehearsal !!!
|
|
|
|
|
Patje wrote:
Even if our application is running in e.g. German or Italian, the strings in the common control (and common dialogs) remain in English.
Commctrls are part of the OS, and thus are localized with the same language than your OS language.
You have more freedom when it comes with MFC controls, where you have a MFC42xxxloc.dll DLL to choose for redistribution (see MSDEV CD for more).
Patje wrote:
From the MSDN documentation I found that there is a function InitMUILanguage than you can use to change the language of common controls. I used it as follows...But apparently, it does not seem to work.
So you think each OS installation features all controls in all possible languages. Of course not.
MUI is a totally different thing. It's introduced with XP only, and it's a set of system dlls aimed to "enhance" dynamic language switch by hooking ::LoadLibrary. It works with the installation of localized MUI dlls (which you have to install on top of your OS anyway, on a language-by-language basis).
|
|
|
|
|
.S.Rod. wrote:
MUI is a totally different thing. It's introduced with XP only
Strange, according to the MSDN documentation:
The common controls have built-in support for national languages. These features simplify the implementation of localized applications.
And it works as long as I change the 'locale' in the control Panel. I have a standard Windows 2000. Setting the language to German gives me german month names and a 'Heute' button (instead of Today). And I'm sure I'm using normal common controls, no MFC controls.
.S.Rod. wrote:
Commctrls are part of the OS, and thus are localized with the same language than your OS language.
According to the documentation of InitMUILanguage:
Enables an application to specify a language to be used with the common controls that is different than the system language. and
Windows NT/2000: Requires Windows 2000 (or Windows NT 4 with Internet Explorer 5 or later installed).
Not a word about XP required.
What am I missing ?
<marquee>Enjoy life, this is not a rehearsal !!!
|
|
|
|
|
are there any known issues with dispatching VARIANTs from one app to another in VS.NET?
when dispatching BSTRs and the like, everything goes fine. i tried some older applications (compiled under VS6) on my computer and they do work properly (using VARIANT as a paramter through automation).
i built the very easiest example of one server-app exporting one function VARIANT Test(VARIANT var); and one client using this function through automation. when debugging the client, the server gets properly loaded and the mfc-dispatchwrappers all do their job well (at the and of F11-ing the client the VARIANT-argument is ok as i constructed it). but when i debug the server, the VARIANT-argument getting in there is crap. moreover: it is different for each debugging-session.
as the proper functions get called, i assume, there's everything ok with registring the component and that stuff.
is there anything known about this issue? any hints and ideas are greatly appreciated...
thx.
:wq
|
|
|
|
|
it even doesn't work, when i compile the server as a dll.
in that case, everything is running in the same process and i can debug each and every step. just before the server-function is called, there are some fancy stack-creation and inline-assembler thingies in the code.
when the function is called then, there's crap on the stack!
ah. just found one more: even the return address seems to be corrupt. when i return from the server-function into the mfc-wrapper-code i end up higher than i started! 
the result is: the server-function is entered again and afterwards that inline-assembler-code wants to derefence a NULL-pointer. bang! 
maybe there's an error in the VC++.NET implementation of that code?
or maybe i have some wrong settings in my project?
weird! 
:wq
|
|
|
|
|
ok. i cross-checked that thing with VS6 and the following turns out:
the VS6-client crashes when using the VS.NET server
the VS.NET-client crashes when using the VS.NET server
the VS6-client works correctly with the VS6 server
the VS.NET-client works correctly with the VS6 server
so i believe there is a bug in the VS.NET automation-server MFC-implementation when using a VARIANT-parameter. and now? how can i report this.
or maybe i made a mistake somewhere, but i don't know where...
:wq
|
|
|
|
|
I draw a transparent ownerdraw button.
So I did override OnEraseBkgnd() and draw my stuff in DrawItem(), with strange result. If I use device context from LPDRAWITEMSTRUCT the result is strange... if I use my own DC then all looks fine.
Can someone explain this behaviour to me? Am I doing something terribly wrong or bad? Thanks for help!
void CMyButton::DrawItem(LPDRAWITEMSTRUCT lpDIS)
{
CClientDC dc(this);
CRect rect = lpDIS->rcItem;
DrawMyGrafic(&rect, &dc);
}
BOOL CMyButton::OnEraseBkgnd(CDC* pDC)
{
return TRUE;
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
