Is this idea viable? (about dll and namespace) - C / C++ / MFC Discussion Boards

Re: change buttons style

Nishad S27-Sep-07 2:55

Nishad S

27-Sep-07 2:55

mitok wrote:
but can't use BS_BITMAP or other button style by some reasons.

AFAIK without BS_OWNERDRAW, customization of button will be difficult. And I am not sure about the possibilities of the window hook for this case...

Can you describe a little more about why you cant use the styles?

- NS -

Re: change buttons style

mitok27-Sep-07 3:13

mitok

27-Sep-07 3:13

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.

Re: change buttons style

Nishad S27-Sep-07 3:30

Nishad S

27-Sep-07 3:30

Then you can use BS_OWNERDRAW and draw the bitmap by yourself, not depending on SS_BITMAP. Did you try it?

- NS -

Re: change buttons style

mitok27-Sep-07 3:52

mitok

27-Sep-07 3:52

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?

Re: change buttons style

Nishad S27-Sep-07 4:06

Nishad S

27-Sep-07 4:06

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... Smile | :)

- NS -

Re: change buttons style

Naveen27-Sep-07 2:48

Naveen

27-Sep-07 2:48

better you write a theme...

nave

[OpenedFileFinder]

Re: change buttons style

Nishad S27-Sep-07 2:56

Nishad S

27-Sep-07 2:56

He need it only in his application... Frown | :(

- NS -

Is this idea viable? (about dll and namespace)

Nelek27-Sep-07 0:05

Nelek

27-Sep-07 0:05

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 ()
{
//DialogBox to change the mode and returning "write"
;
if (write::CheckValidDll () )
	using namespace write;
;
WriteCodeToPLC (param1, param2, …);
;
//more code
return;
}
;
;
;
//Somewhere else in the same CMonitorCenter
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

Wink | ;)

Re: Is this idea viable? (about dll and namespace)

Cedric Moonen27-Sep-07 0:50

Cedric Moonen

27-Sep-07 0:50

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 Confused | :confused:

? 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 ?

Cédric Moonen
Software developer

Charting control [v1.2]

Re: Is this idea viable? (about dll and namespace)

Nelek27-Sep-07 1:49

Nelek

27-Sep-07 1:49

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).

Sigh | :sigh:

You are totally right, I don't know what I was thinking about Unsure | :~

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 Big Grin | :-D

Articles on SAFEARRAY for implementing in VC++

shir_k26-Sep-07 23:54

shir_k

26-Sep-07 23:54

Hi,

Plz let me know the links for safearray(variant type) to implement in VC++

Thanks

Re: Articles on SAFEARRAY for implementing in VC++

toxcct27-Sep-07 0:07

toxcct

27-Sep-07 0:07

blockquote class="FQ">

shir_k wrote:

Plz let me know the links for safearray(variant type) to implement in VC++

THE Ultimate Link[^]

[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]

setfocus

bhogavalli suresh26-Sep-07 23:40

bhogavalli suresh

26-Sep-07 23:40

how do i set focus in one of my edit control in property sheet

Re: setfocus

Stephen Hewitt27-Sep-07 14:47

Stephen Hewitt

27-Sep-07 14:47

You shouldn't use SetFocus in dialogs. See here[^] for details.

Steve

Re: setfocus

Sunil P V26-Sep-07 23:52

Sunil P V

26-Sep-07 23:52

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

Re: setfocus

Stephen Hewitt27-Sep-07 14:48

Stephen Hewitt

27-Sep-07 14:48

You shouldn't use SetFocus in dialogs. See here[^] for details.

Steve

Re: setfocus

zakkas248326-Sep-07 23:54

zakkas2483

26-Sep-07 23:54

GetDlgItem( ID )->SetCapture();

Where ID is the id Of the Edit control
ok.

hiren thakkar

Re: setfocus

Naveen27-Sep-07 0:17

Naveen

27-Sep-07 0:17

zakkas2483 wrote:
GetDlgItem( ID )->SetCapture();

Purpose of SetCapture() API is different.Did you really mean SetCapture itself?

nave

[OpenedFileFinder]

Re: setfocus

zakkas248327-Sep-07 0:40

zakkas2483

27-Sep-07 0:40

Sorry,i was wrong.
code is like that
CEdit* clEdit = (CEdit*)getDlgItem( ID );
clEdit->SetFocus();

sorry again for mistake.

Thanks.

hiren thakkar

Re: setfocus

Stephen Hewitt27-Sep-07 14:48

Stephen Hewitt

27-Sep-07 14:48

You shouldn't use SetFocus in dialogs. See here[^] for details.

Steve

Re: setfocus

zakkas248327-Sep-07 20:59

zakkas2483

27-Sep-07 20:59

Thanks Steve ....Thank You very much

Re: setfocus

Nishad S27-Sep-07 1:45

Nishad S

27-Sep-07 1:45

GotoDlgCtrl( GetDlgItem( IDC_EDIT ));

- NS -

Re: setfocus

David Crow27-Sep-07 3:11

David Crow

27-Sep-07 3:11

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

Re: setfocus

Stephen Hewitt30-Sep-07 15:31

Stephen Hewitt

30-Sep-07 15:31

If it's a trick question it's a very tricky one -- you shouldn't use SetFocus in dialogs. See here[^] for details.

Steve

Re: setfocus

Mark Salsbery27-Sep-07 5:36

Mark Salsbery

27-Sep-07 5:36

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]

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.