|
yes, i can, but it's quite another matter. i develop a plugin for Windows Explorer of Windows Vista. it's button, which is located near Back & Forward buttons, but vista glass blur any picture, which is inserted by me (using BS_BITMAP etc.). i want to redefine system styles, then style of my button doesn't depend on vista glass.
|
|
|
|
|
Then you can use BS_OWNERDRAW and draw the bitmap by yourself, not depending on SS_BITMAP. Did you try it?
- NS -
|
|
|
|
|
yes, i've already used BS_OWNERDRAW as button style, but it didn't help me. AFAIK SS_BITMAP relates static element, how can i use static element? what for? and one more question : if BS_OWNERDRAW is used , button is drawn WM_DRAWITEM notification of parent window, but my button has parent window - Explorer, which is created not by me?
|
|
|
|
|
mitok wrote: AFAIK SS_BITMAP relates static element
Sorry, I meant BS_
mitok wrote: if BS_OWNERDRAW is used , button is drawn WM_DRAWITEM notification of parent window
Oh... now I understood...
Then my opinion is that you should create a custom control which will send BN_CLICKED notification. But take it as only the last resort... 
- NS -
|
|
|
|
|
better you write a theme...
|
|
|
|
|
He need it only in his application... 
- NS -
|
|
|
|
|
Hi all,
I would like to know if the following idea is correct or is better to do it in other way. (I’m not asking for particular code, I will try it in my own).
I’m just starting with DLLs programming. In my project I need to communicate my Win32 *.exe with a PLC. To do that I have found a DLL that makes the connection, but the problem now is how to read from / write to the PLC. The problem I have is that the WriteTo functions have to be in a DLL for security to avoid as many problems as possible.
In my *.exe I have a view “MonitorCenterView” where all the functionality of the connection will be used through the third party dll. The read functions are going to be programmed there, but the write (as I said) in a DLL. Changing the “working mode” want to be sure my file is there, so I want to check out if one member parameter in the dll has a concrete value (like a license or a password) and if all is good then use the function of the dll.
I have thought to make something like this:
including the *.lib to have the directions/links to the functions in the dll in my *.exe but delivering only the *.dll when I want to.
void CMonitorCenterView::OnChangeWorkingMode ()
{
;
if (write::CheckValidDll () )
using namespace write;
;
WriteCodeToPLC (param1, param2, …);
;
return;
}
;
;
;
void CMonitorCenterView::WriteCodeToPLC (param1, param2, …)
{
MessageBox (NULL, "This function is not allowed without the \"write.dll\". Please contact with XXXX", "Error", MB_OK);
}
So when the validation returns TRUE, then the function WriteCodeToPLC (…) will be called from the dll and do its job uploading the code. But if the validation returns FALSE, then the WriteCodeToPLC (...) will be called from the actual class and give the message box with the error.
One question please: If I use the using namespace XXX… Does it just have local validation as a variable defined in the function? Or is it global and need to be “reseted” after? How can abort it afterwards if needed?
Sorry for the extension and thanks for any comment / suggestion / correction, everything will be welcome
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
I'm not sure I understood everything correctly. First, maybe some points:
Nelek wrote: The problem I have is that the WriteTo functions have to be in a DLL for security to avoid as many problems as possible.
Why is it so  ? Which security problems are you talking about ? Putting the code in the dll won't change anything.
Nelek wrote: Changing the “working mode” want to be sure my file is there, so I want to check out if one member parameter in the dll has a concrete value (like a license or a password) and if all is good then use the function of the dll.
I didn't understand what you meant by "Changing working mode", but anyway: you probably load your dll implicitely (meaning that you use a lib file that contains the code to load your dll). If that is the case, then if your dll is missing, your program won't even start (you'll get a nice error message saying that the dll is missing as soon as you start your app). You could also load the dll explicitely, by making use of LoadLibrary and GetProcAddress functions. If you do that, you'll have full control on when your dll is loaded (but it is a little bit more complicated to use, specifically if you use classes). In that case, the LoadLibrary will return NULL if the dll cannot be loaded (e.g. missing).
Thus, for both scenarios, it doesn,t make any sense to call a function from your dll to see if it is present (because if you come to the point were you are able to call a function from the dll, then it means that your dll is present).
Nelek wrote: including the *.lib to have the directions/links to the functions in the dll in my *.exe but delivering only the *.dll when I want to.
That will fail, as I explained before: if the dll is not present, you won't be able to start your program.
And for the namespace question, I didn't really understood what you meant. Isn't it simpler (if you could do it) that if you detect the dll, you call the function from it, otherwise you call another function from your class (with a different name for example). Why do you want to use namespaces for that ?
|
|
|
|
|
First of all... Thanks. After reading you I have notice that is not as good as I thought.
Nelek wrote:
The problem I have is that the WriteTo functions have to be in a DLL for security to avoid as many problems as possible.
Cedric Moonen wrote:
Why is it so ? Which security problems are you talking about ? Putting the code in the dll won't change anything.
That's what my chef want. I explain it better. He want that the programm has the functionality to write down into a PLC, but he wants this functionality to depend on a dll. So that anyone can use my software to write down into the PLC if they don't have our dll. So the programm should work with or without the dll in the folder. But the functionality should be only available when it is there.
Cedric Moonen wrote:
Thus, for both scenarios, it doesn,t make any sense to call a function from your dll to see if it is present (because if you come to the point were you are able to call a function from the dll, then it means that your dll is present).
 You are totally right, I don't know what I was thinking about 
I will look for info about the LoadLibrary and GetProcAddress. Actually if the return value is NULL when dll is not there... then I can anyways choose between function and messagebox. And that's exactly what I wanted. Thanks 
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Hi,
Plz let me know the links for safearray(variant type) to implement in VC++
Thanks
|
|
|
|
|
| blockquote class="FQ"> shir_k wrote: Plz let me know the links for safearray(variant type) to implement in VC++
THE Ultimate Link[^]
|
|
|
|
|
how do i set focus in one of my edit control in property sheet
|
|
|
|
|
You shouldn't use SetFocus in dialogs. See here[^] for details.
Steve
|
|
|
|
|
Assume the ID of your edit control is IDC_EDIT_NAMETAG,
to set the focus do the following:
CWnd* pEditCtrl = GetDlgItem(IDC_EDIT_NAMETAG);
pEditCtrl->SetFocus();
Sunil
|
|
|
|
|
You shouldn't use SetFocus in dialogs. See here[^] for details.
Steve
|
|
|
|
|
GetDlgItem( ID )->SetCapture();
Where ID is the id Of the Edit control
ok.
hiren thakkar
|
|
|
|
|
zakkas2483 wrote: GetDlgItem( ID )->SetCapture();
Purpose of SetCapture() API is different.Did you really mean SetCapture itself?
|
|
|
|
|
Sorry,i was wrong.
code is like that
CEdit* clEdit = (CEdit*)getDlgItem( ID );
clEdit->SetFocus();
sorry again for mistake.
Thanks.
hiren thakkar
|
|
|
|
|
You shouldn't use SetFocus in dialogs. See here[^] for details.
Steve
|
|
|
|
|
Thanks Steve ....Thank You very much
|
|
|
|
|
GotoDlgCtrl( GetDlgItem( IDC_EDIT ));
- NS -
|
|
|
|
|
Is this a trick question? The subject of your post should be a clue.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
If it's a trick question it's a very tricky one -- you shouldn't use SetFocus in dialogs. See here[^] for details.
Steve
|
|
|
|
|
To get more/better behavior than SetFocus() with edit controls,
I would recommend CDialog::GotoDlgCtrl() (MFC) or WM_NEXTDLGCTL (Win32).
(as stated by NS17)
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
You shouldn't use SetFocus in dialogs. See here[^] for details.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
