|
Joaquín M López Muñoz wrote:
The problem must lie elsewhere. Is TEXT also undefined?
Yes. I believe the problem lies elsewhere [actually I have a guess as to the "elsewhere"]
I got an error message [actually a warning] that the unicode dll could not be loaded. So for some strange reason my Win 98 does not support unicode
Nish
My most recent CP article :-
A newbie's elementary guide to spawning processes
www.busterboy.org
|
|
|
|
|
Nish [BusterBoy] wrote:
So for some strange reason my Win 98 does not support unicode
Windows 3/95/98/ME do not support unicode, Windows NT/2k/XP do.
- Matt Newman
-Sonork ID: 100.11179:BestSnowman
Frankly AOL should stick to what it does best: Fooling millions of americans into believing that it, AOL, is the web. -Paul Watson
|
|
|
|
|
MFC v6 unicode DLLs will NOT load on the 9x platforms.
If you really want to do Unicode on 9x, you can use MSLU (a.k.a. Unicows). It is a GREAT little package that MS did that thunks all the Unicode calls down to ANSI calls on 9x. We use it in our product.
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?
|
|
|
|
|
Hello
I was playing around with ATL and find that when we have a function that takes a string as in or out parameters we always use BSTR*. Why don't we use just BSTR? Is it for the obvious pass by pointer reasons?
For example :-
interface INishFirst : IDispatch
{
[id(1), helpstring("method GetString")] HRESULT GetString([in] BSTR* pbstrInString, [out,retval] BSTR* pbstrOutString);
};
Could I have used BSTR there, somehow?
Nish
My most recent CP article :-
A newbie's elementary guide to spawning processes
www.busterboy.org
|
|
|
|
|
Hi Nish,
I think that if you forget the fact that BSTR is really a pointer, then you'll see the answer. If instead of BSTR you were using longs, for example, to pass an [out] parameter, it would be no good having [out, retval] long lResult, as lResult would be copied from the caller and placed on the stack. When the function exits, the caller's lResult would have the same value as it did before the call.
So, in the above example, I wouldn't bother passing in BSTR * for the [in] parameter, but you need to have BSTR * for the [out] parameter so that the caller gets the updated value when the COM method exits.
Sorry, that reads as quite confusing. Hope it helps, though.
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
|
That is true, but it's not like an ordinary (char *), because the four(?) bytes in front of the location pointed at by the BSTR contain the length of the BSTR. Because of this, I think, it's better to think of a BSTR as an encapsulated data type and not rely on it being a pointer to something. Again, I'm no expert.
What I do know, though, is that if you tried to pass a BSTR as an [out] parameter, it would not be accepted by VB (or other Automation-compatible languages). Of course, that may not be an issue for you, but you never know...
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
Thanks Derek. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Derek Waters wrote:
What I do know, though, is that if you tried to pass a BSTR as an [out] parameter, it would not be accepted by VB (or other Automation-compatible languages). Of course, that may not be an issue for you, but you never know...
It would be an issue for me. My primary intention in learning ATL is so that I can try and write some components for use from ASP.
Nish
My most recent CP article :-
A newbie's elementary guide to spawning processes
www.busterboy.org
|
|
|
|
|
Oh yeah, the marshalling for a BSTR * is probably smaller/quicker than BSTR. Maybe. I'm no expert...
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
The marshalling speed is not affected by whether you use a BSTR or a BSTR*.
When the COM object is instantiated as an INPROC_SERVER, the BSTR has one less pointer dereference, then memory is read from both types in the same way.
When the object is instantiated as a LOCAL_SERVER, or a REMOTE_SERVER, the data from both strings is completely packaged up and marshalled to the the client process. The time that it takes to dereference the extra pointer for the BSTR* is trivial compared to the process context switch or the network latency that is involved in marshallig the data.
Basically what it boils down to is the fact that you should use a normal variable type for input parameters, and pointers to the data type for output parameters.
If you use a pointer for input parameters, that is one extra check that needs to be made in order to guarentee that the pointer is valid, when this check does not have to be made when the value is input.
Because there is no pass by reference in COM, the only other way to return a value through a parameter is through a pointer.
|
|
|
|
|
Another point Nish:
[out] parameter should always be a pointer
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
Hi codegurus there.
I am doing some network programming using MFC these days. I have two application, one is server, one is client. For server, I make it an un-blocking one using WSAAsyncSelect, and specify to respond to the following network event:
FD_READ | FD_WRITE | FD_ACCEPT | FD_CLOSE
At the client end, it's simple. I have three menu item, one is open_connection, one is close_connection, the other is send_receive. Here's part of my code for client:
OnConnectionClose()
{ shutdown(mysocket, SD_SEND);
closesocket(mysocket);
}
OnConnectionOpen()
{ mysocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
connect(mysocket, (LPSOCKADDR)&saServer, sizeof(saServer));
}
OnSendReceive()
{ send(mysocket, szBuf, strlen(szBuf),0);
recv(mysocket, szBuf, sizeof(szBuf), 0);
}
And at server end, I respond to the network event like this:
OnNetWorkEvent(WPARAM wParam, LPARAM lParam)
{
switch(WSASELECTEVENT(lParam)
{
case FD_CLOSE:
closesocket(wParam);
TRACE("FD_CLOSE received\n");
break;
case FD_ACCEPT:
... ...
}
}
the problem here is: on client end, if I do "open_connection", then "close_connection", the server end will receive the FD_CLOSE event. But if I do "open_connection", "send_receive", then "close_connection", the server end will not receive the FD_CLOSE event. All other events are handled correctly. Could anybody tell me what's wrong with my coding?
Thank you all very much in advance!
|
|
|
|
|
FD_CLOSE will only be notified when there's no more data to read (you can think of it as the EOF after reading all data from a file). So it is possible that your server app is not consuming all the pending input and thus gets never notified about FD_CLOSE.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thank you very much for the hint!
One more question,  When my client call connect(), the server will be notified by FD_ACCEPT event. This is cool. But right after that, the server will be notified by a FD_WRITE event. Why?
|
|
|
|
|
FD_WRITE is notified (for a particular socket) whenever the socket is able to accept data for output. So:- If you are calling
accept on the FD_ACCEPT handler, it is not only legal but indeed expected that you receive an FD_WRITE right after that.
- If you are not calling
accept on the FD_ACCEPT handler, then the behavior you're observing is weird.
If you'd like to learn more about Winsock programming, Warren Young maintains an excellent Winsock Programmer's FAQ.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
thank you a lot!![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif) I am checking the FAQ out..
|
|
|
|
|
Hi all,
I have WinXP on my system ...
I could run all 3d programs before i install VS.NET ...
When i installed VS .NET then now i can't run any 3d programs because my computer hangs !!!
What is wrong ?
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
Maybe VS.NET installed a different version of DirectX?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi again, thanks for reply ...
hmmm yes, maybe ...
But how can i solve it ?
Is there any way ?
(I don't think so  )
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
I have some code that uses SHBrowseForFolder() to let the user browse for a folder. The problem is, if the user selects a folder but later needs to select a different folder, i can't make it default back to the previously selected folder. There must be some simple way to do this, right?
farewell goodnight last one out turn out the lights Smashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
There must be some simple way to do this, right?
There is a way, but it's anything except simple. Fortunately, Kenneth M. Reed wrote a MFC Wrapper for SHBrowseForFolder which does the hard job for you.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
This looks like it should work. Thanks!
farewell goodnight last one out turn out the lights Smashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
SHBrowseForFolder lets you use a callback function. In your callback, handle the BFFM_INITIALIZED notification and set the initial selection. See BrowseCallbackProc in MSDN for more info.
--Mike--
Fetchez la vache!
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan and Jamie Salé.
|
|
|
|
|
|
Wow fancy!
Thanks man, this is exactly what i need!
farewell goodnight last one out turn out the lights Smashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
