C / C++ / MFC

Nish Nishant12-Jun-02 14:36

Nish Nishant

12-Jun-02 14:36

Read :-

http://www.codeproject.com/useritems/dlgboxtricks.asp

There is a tip there called "Removing the task bar icon of your dialog based App"

Use the same technique mentioned there.

Nish

Author of the romantic comedy

Summer Love and Some more Cricket [New Win]

Buy it, read it and admire me Smile | :)

Gary Kirkham13-Jun-02 2:31

Gary Kirkham

13-Jun-02 2:31

Thanks for the reply. I found an easier way (in a reply to an article)...just set the dialog style to Tool Window. Now I have another problem to work through...I want the modeless dialog window to always be on top, so I made it the topmost window...works fine. I want to keep it from grabbing the focus every time I move or resize the MDI Mainframe window... the mainframe window is the dialog's parent.

Any Ideas?

Also, the dialog remains on top when I switch to other applications like Word or Excel...Does anyone now how to stop this behavior?

C^hris L^osinger13-Jun-02 4:34

13-Jun-02 4:34

if you make the desktop the parent of the dialog (ie. use NULL as the parent), it will be completely independent of the application's focus.

-c

Cheap Oil. It's worth it!

Image Processing?

Gary Kirkham13-Jun-02 10:27

Gary Kirkham

13-Jun-02 10:27

I tried what you suggested...It made no difference...The modeless dialog still grabs focus when I resize the mainframe window and it is still in front of other, non application, windows when when I switch to other applications

Question of style

Navin12-Jun-02 8:28

12-Jun-02 8:28

Let's say you are using MFC, and have a function that accepts a constant string as its argument. Which is better style:

1. int SomeFunction(LPCTSTR stringArgument);
2. int SomeFunction(const CString &stringArgument);

Most MFC functions use a form of number 1, but it seems number 2 is more "object oriented", at least by appearance. I guess number 2 would have to create a CString object on the fly if you specifiy a constant string, so there may be a performance difference..?

Or am I just being anal and it doesn't make that much of a difference in real life? Big Grin | :-D

No generalization is 100% true.
Not even this one.

dazinith12-Jun-02 8:34

dazinith

12-Jun-02 8:34

/me eagerly waits others opinions.. Smile | :)

i'd say number 2, because i hate 'LPCTSTR', i do my best to avoid that damn keyword .. prolly cause im scured..

-dz

Navin12-Jun-02 9:14

12-Jun-02 9:14

dazinith wrote:
i'd say number 2, because i hate 'LPCTSTR', i do my best to avoid that damn keyword .. prolly cause im scured..

Yeah I know what you mean, Windows and it's butt-ugly keywords. Big Grin | :-D

But it is nice to have something that'll work with Unicode, multi-byte, and ANSI builds.. otherwise I'd just good old const char *.

No generalization is 100% true.
Not even this one.

NormDroid12-Jun-02 9:44

NormDroid

12-Jun-02 9:44

const CString& sParam.

There is a good aricle in MSJ now MSDN magazine around '95/'95 which describe the best method calls with LPSTR/LPCSTR/CString/CString& I think the article could be by Jeff Process/Jeff Richter or even Paul De Loucia - sorry Paul if I spelt your name wrong.

Normski. - Professional Windows Programmer

Navin12-Jun-02 10:06

12-Jun-02 10:06

Soudns all right, but won't that create a temporary CString object to pass into the function? Of course, that may be such a small overhead that nobody will ever notice.. Unsure | :~

No generalization is 100% true.
Not even this one.

C^hris L^osinger12-Jun-02 10:04

12-Jun-02 10:04

Navin wrote:
won't that create a temporary CString object

yes, it will.

but, it will probably be no big deal (unless it's in a loop or you're passing GB strings, etc.)

-c

Beware the leader who bangs the drums of war to whip the public into patriotic fervor, for patriotism is a double-edged sword. It emboldens the blood and narrows the mind. When the drums of war have reached a fever pitch, the blood boils and the mind closed, the leader will not need to seize the rights of citizens. Rather, infused with fear and blinded by patriotism, they will gladly offer up their rights. How do I know? For this is what I have done. And I am Caesar.

Shog⁹12-Jun-02 13:21

Shog⁹

12-Jun-02 13:21

C^hris L^osinger wrote:
yes, it will.

What? Really? Even if he's passing by reference? Confused | :confused:

--------
Hey you Whitehouse, ha ha, charade you are
You house proud town mouse, ha ha, charade you are

-- Pink Floyd, Pigs (Three Different Ones)

C^hris L^osinger12-Jun-02 13:26

12-Jun-02 13:26

you can't pass a char * as a CString - they ain't the same thing.

try it.

-c

Cheap Oil. It's worth it!

Image Processing?

Shog⁹12-Jun-02 13:28

Shog⁹

12-Jun-02 13:28

*slaps self*
Sorry, didn't read the question correctly. Thought he was passing a CString as the parameter Blush | :O

--------
Hey you Whitehouse, ha ha, charade you are
You house proud town mouse, ha ha, charade you are

-- Pink Floyd, Pigs (Three Different Ones)

redeemer12-Jun-02 10:23

redeemer

12-Jun-02 10:23

I use number one exept no unicode support and i don't use LPTSTR, i don't like it.

const char *stringArgument

LPCTSTR = A 32-bit pointer to a constant character string that is portable for Unicode and DBCS.

Navin12-Jun-02 15:41

Re: Ok, here is the run down...

12-Jun-02 15:41

I never use LPTSTR. I may have a TCHAR array here and there if I need to pass a non-const string to a system API. But I never use functions that take LPTSTR - I'd use a non-const reference to a CString in that case.

For clarification, what I meant about a parameter creating a temporary CString object is in this scenario. I guess it would only matter, as Chris Losinger said, if you pass in great big strings or are in a loop or something like that.

void SomeFunc(const CString & Green Alien | [Alien]

)
{
...
}

...
// This will create a temporary CString to pass into
// SomeFunc.
SomeFunc("This is not a C-String!");

// But this won't.
CString Green Alien | [Alien]

= "This one is.";
SomeFunc( Green Alien | [Alien]

);

Yes, I know it is against C++ standards to use an icon as a variable name. Smile | :)

No generalization is 100% true.
Not even this one.

Tim Smith12-Jun-02 16:11

Tim Smith

12-Jun-02 16:11

You have to look at what you are doing with your string. What is coming in and how it will be used inside the routine.

Outside routine: CString
Inside routine: CString (for example, storing into a local str var)
Argument: const CString &

In this case, you are able to take advantage of the reference counting used by CString. No duplicate strings will be created. (GOOD)

Outside routine: CString
Inside routine: CString (for example, storing into a local str var)
Argument: LPCTSTR

In this case, the CString will just pass the pointer to the internal string. However, once that string is used as a CString inside of the routine, a duplicate will have to be made. (BAD)

Outside routine: LPCTSTR
Inside routine: CString (for example, storing into a local str var)
Argument: const CString &

In this case, a CString will have to be created prior to the routine being invoked. However, since the routine will actually be using the CString internally, it would have had to have been created anyway. No performance loss. (GOOD)

Outside routine: LPCTSTR
Inside routine: CString (for example, storing into a local str var)
Argument: LPCTSTR

In this case, the string is being passed directly into the routine. Then internally a CString is being created. However, the same would have been true if the argument was CString. (GOOD)

Outside routine: CString
Inside routine: LPCTSTR (maybe a call to _tcscmp)
Argument: const CString &

In this case, the string is passed directly in and the routine just uses the (LPCTSTR) operator in CString to access the contents. No performance loss. (GOOD)

Outside routine: CString
Inside routine: LPCTSTR (maybe a call to _tcscmp)
Argument: LPCTSTR

In this case, the CString will just pass the pointer to the internal string. The routine will use the pointer as is. (GOOD)

Outside routine: LPCTSTR
Inside routine: LPCTSTR (maybe a call to _tcscmp)
Argument: const CString &

In this case, a copy of the string will get created to be passed as a CString. Then the CString is just dereferneced. Needless creation of temp string. (BAD)

Outside routine: LPCTSTR
Inside routine: LPCTSTR (maybe a call to _tcscmp)
Argument: LPCTSTR

In this case, the string is being used as is. No temp objects. (GOOD)

SOOOOOOO

If you total it all up:

Case 1:

If inside the routine you are using the string as a CString:

Argument as CString: 2 good cases, no bad.
Argument as LPCTSTR: 1 good case, 1 bad case.

So, when the routine will be using the string as a CString, there is no reason to not use "const CString &" for the argument.

Case 2:

If inside the routine you are using the string as a LPCTSTR:

Argument as CString: 1 good case, 1 bad case.
Arguemnt as LPCTSTR: 2 good cases, no bad cases.

So, when the routine will be using the string as a LPCTSTR, there is no reason to not use "LPCTSTR".

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

help

12-Jun-02 8:09

I have a program Visual C++ which is connecting to SQL 2000. Because the SQL 2000 set to WindowsNT authorization I can't use the 'sa'. How do I deal with this problem??
Cry | :((

Re: help

Michael P Butler12-Jun-02 11:16

Michael P Butler

12-Jun-02 11:16

You need to make sure that your SQL database tables has the NT users assigned to it via the users in SQL Server enterprise manager.

Michael Smile | :)

"Eureka" is Greek for "This bath is too hot"

ReadFile from Comm port

JohnnyG12-Jun-02 7:19

JohnnyG

12-Jun-02 7:19

This code is from the mttty sample in MSDN but I'm not sure how ReadFile works. It says it does not return until it encounters an error or the actual amount of bytes read equals what was specified as a parameter. I'm wondering how this code works because it can only write the data to disk in the else block or after the WaitForMultipleObjects call. I've modified some of the code so that OutputABuffer() should now be OutputABufferToFile(). I'm a little confused how threading works here. If ReadFile doesn't return until 512 bytes are read then how does the WaitForMultipleObjects apply? It looks like the code in the WaitForMultipleObjects section does the same thing...write to a file, as the code after the else block of the ReadFile call.

#define AMOUNT_TO_READ 512

while ( !fThreadDone )
{

//
// If no reading is allowed, then set flag to
// make it look like a read is already outstanding.
//
if (NOREADING( TTYInfo ))
fWaitingOnRead = TRUE;

//
// if no read is outstanding, then issue another one
//
if (!fWaitingOnRead)
{
if (!ReadFile(COMDEV(TTYInfo), lpBuf, AMOUNT_TO_READ, &dwRead, &osReader))
{
if (GetLastError() != ERROR_IO_PENDING) // read not delayed?
ErrorInComm("ReadFile in ReaderAndStatusProc");

fWaitingOnRead = TRUE;
}
else
{ // read completed immediately
if ((dwRead != MAX_READ_BUFFER) && SHOWTIMEOUTS(TTYInfo))
UpdateStatus("Read timed out immediately.\r\n");

// modify section here to assemble 20 byte messages before writing to disk
if (dwRead)
{
if(gdwReceiveState == RECEIVE_CAPTURED)
{
OutputABufferToFile(ghFileCapture, lpBuf, dwRead);

}
}
}
}

.
.
.
//
// wait for pending operations to complete
//
if ( fWaitingOnStat && fWaitingOnRead )
{
dwRes = WaitForMultipleObjects(NUM_READSTAT_HANDLES, hArray, FALSE, STATUS_CHECK_TIMEOUT);
switch(dwRes)
{
//
// read completed
//
case WAIT_OBJECT_0:
if (!GetOverlappedResult(COMDEV(TTYInfo), &osReader, &dwRead, FALSE)) {
if (GetLastError() == ERROR_OPERATION_ABORTED)
UpdateStatus("Read aborted\r\n");
else
ErrorInComm("GetOverlappedResult (in Reader)");
}
else { // read completed successfully
if ((dwRead != MAX_READ_BUFFER) && SHOWTIMEOUTS(TTYInfo))
UpdateStatus("Read timed out overlapped.\r\n");

if (dwRead)
OutputABufferToFile(ghFileCapture, lpBuf, dwRead);
// OutputABuffer(hTTY, lpBuf, dwRead);
}

fWaitingOnRead = FALSE;
break;
.
.
.
case WAIT_TIMEOUT:
.
.
} // END WHILE LOOP

Re: ReadFile from Comm port

JohnnyG12-Jun-02 10:16

JohnnyG

12-Jun-02 10:16

I sort of figured it out. The operation is overlapped so it would return from ReadFile() immediately. So, it looks like I'll have to make a function that will package my data into 20 byte messages - I append time and port number to each 8 or 14 byte messages. And, this function will have to be called from the else block and in the WaitForMultipleObjects switch statement. Sound good?

Windows Messaging Timing and Threads

SanShou12-Jun-02 6:41

SanShou

12-Jun-02 6:41

Allright, I have some major questions that maybe some one can help me with.

First I am writing a Windows GUI that interfaces to an embedded system via RS232 messages. In order to transmit these messages, I was asked to create a three level OSI protocol stack (transport, network, and datalink.) This stack then communicates back to the application via windows messages (WM_COMM_SENT, WM_COMM_RETRY, and so on...) This uses two threads (send and recieve for each layer) but only the transport thread sends messages.

I have a simple callback system where the transport talks only to the CMainFrame class. The mainframe class handles the messages, queries a messages manager, and then the message manager sends out a WM_COMM_CALLBACK message to each window that needs the data.

The problem is, I am currently trying to interact with the box via the new GUI. The GUI handles a button press, issues the send command in the transport just fine and recieves the data back immediately. However I must release or terminate the current windows message before the messages that come back from the communications stack are processed. This works fine because most of the GUI message handlers are short..., but finally to my question?

Is there a case where during a button press that sends out say 128 messages to handle some of the return messages before the button press message returns back to the message pump? Or is there better system for returning information from the transport... I guess after working 16 hours a day for three weeks to get a demo ready for a trade show and being the only one in a small company that can handle this, I am a little fried and need help walking through the Windows messaging world and threads...

My only other ideas are to release control and wait for the callback before sending the next message, but that limits the functionality of placing a multi-message buffer in the comm stack... or to write a thread that GUI message starts up and then lets it ride until all the messages are sent, however I am already handling so many threads... In other words how many threads are too many threads Confused | :confused:

.

Any help is appreciated...

Thanks,
Brian

Stop the hatred, free the Mallocs.

Re: Windows Messaging Timing and Threads

NormDroid12-Jun-02 9:40

NormDroid

12-Jun-02 9:40

Any process which is syncronchous inside the GUI, should be seperated by implementing within a thread.

I guess from your description.

I would have a thread to process requests from the GUI.
Eg.

CProcessTread
{
AddRequest(...)
ProcessQueue(...)
etc.

AddFeedBackDelegate(...)
}

This frees the GUI to get on with it's own business. "AddFeedBackDelegate" would take call back function to your GUI so that you can be notified of message receipt/delivery. Alternatively you could Send requests back to the GUI via custom WM_APP + 0x??? messages.

I hope I make since, feel free to contact me with a more descriptive email.

Normski. - Professional Windows Programmer

Callbakc Functions

arthivjii12-Jun-02 6:36

arthivjii

12-Jun-02 6:36

Hi,
I am begineer in VC++ and C++ programming. I need to write a "Callback function" for performing certain operations in my application.
I need some guidance or article where I can learn about writing callback functions. (Do's and Dont's). I will be greatful to get some information.

Thanks and Regrads,
Arthi

Re: Callbakc Functions

C^hris L^osinger12-Jun-02 6:55