C / C++ / MFC

Re: CAsyncSocket - Client receives some messages but not others

6-Nov-06 12:33

realius222 wrote:
Also, the server is not receiving an OnSend message. It is my understanding from another post that the server should receive an OnSend message after sending to indicate it is ready for another send.

You'll need to call AsyncSelect(FD_WRITE) on the socket for OnSend() to be called by the
framework. You would do this on the socket accepted with Accept(). You may want to use other
flags as well but you at least need FD_WRITE to get OnSend() notification.

realius222 wrote:
All is well except the client does not always get the data that is sent by the server.

With TCP, you need to repeatedly call Receive() (or recv()) on the socket until you get the
number of bytes you are expecting. There's no guarantee that a successful call to Receive() will
return more than one byte. Of course, it usually does. Smile | :)

For example, if, in your OnReceive() handler, you call Receive() to receive 100 bytes and
Receive() returns 50, then you can return from OnReceive() and call Receive() again in the next
OnReceive() call for the remaining 50 bytes. Therefore, you'll need to keep track of how much
you've received and/or how much you are still waiting to receive until you've received what you're
expecting.

Hope that made sense Smile | :)

Mark

iserik6-Nov-06 18:06

iserik

6-Nov-06 18:06

realius222 wrote:
Also, the server is not receiving an OnSend message. It is my understanding from another post that the server should receive an OnSend message after sending to indicate it is ready for another send.

Meaning of OnSend notification is different. The OnSend comes once both after establishing a connection or when WSAAsyncSelect(,,,FD_WRITE) called, which signifies a socket is ready for sending operation. The status “readiness for writing” remains until buffer space becomes available and a send fails with WSAEWOULDBLOCK. When buffer becomes available Windows Sockets notifies an application again. In other words, an application can assume that sends are possible starting from the first OnSend Notification and lasting until a send returns WSAEWOULDBLOCK. Therefore, it’s possible application receive OnSend only once after connecting and may send data via socket any time, in case an outgoing data flow rate less then a network capability.

Regars,
ISerik

ActiveX Controls [modified]

Stober6-Nov-06 11:21

Stober

6-Nov-06 11:21

Using VC++ 2005 Pro, I created the shell of an MFC ActiveX control, then added one property with get/put methods. That compiled ok.

Then I wrote a simple MFC dialog application to test my ActiveX control. Added the control, and gave it a variable name. That all worked ok after some studying about how to accomplish that.

My question is, the *.cpp and *.h files that were added to the MFC project do not contain the set/put methods of the control All those two files contain are the controls constructors. VC++ 6.0 compiler would put all the control's properties and methods in those to files for me. So, with VC++ 2005 how am I supposed to call the property and methods ? The control has a type library, but I don't know how to use it. Will someone please point me to a thread of site that shows how to use ActiveX with this compiler?

Thanks.

[edit]I found out how to create an MFC clas based on the type library, but how to use it in a CDialog application? It should not be this difficult. Mad | :mad:

[/edit]

MAPILogon with Groupwise

yyf6-Nov-06 10:54

yyf

6-Nov-06 10:54

Hi,

I am writing a dll exporting an funcion to send email. Now I got a problem. When my dll was called by another application, the groupwise login dialog will show up, when I click 'Cancel', that login dialog will be gone. However, when my dll was called again, this login dialog won't show up anymore and MAPILogon return SUCCESS_SUCCESS, lhSession is not null. I don't know what's wrong. Can any one tell?

Thanks in advance.

Re: MAPILogon with Groupwise

yyf7-Nov-06 2:21

yyf

7-Nov-06 2:21

nobody knows? Frown | :(

Use exisiting printing methods for Printers in Print Preview

skywalkerking6-Nov-06 10:06

skywalkerking

6-Nov-06 10:06

Dear All,

I am trying to implement print preview feature in a view class. (by implementing onBeginPrinting, onPrint, onEndPrinting) by using my friend's printing methods which are written in C language(his methods are used to print to printer directly). However, The existing method uses all kinds of map mode like MM_TEXT, MM_LOMETRIC, or MM_ISOTROPIC rather than MM_ANISOTROPIC(which is used by print preview feature defaultly). My question is, do I have to convert these mapping modes in existing printing method to MM_ANISOTROPIC? Or there is a easier way to do this?

Thanks for your reply in advance

let's do programming!!

Re: Use exisiting printing methods for Printers in Print Preview"

skywalkerking6-Nov-06 10:26

skywalkerking

6-Nov-06 10:26

Dear All,

Sorry, One more thing to mention. If I choose deskPDF in print setup dialog, the result printed would be exactly the same as that printed to printer. I think deskPDF has this kind of functionality too. My followed question is, how does deskPDF do it? Through pipeline? Is it possbile to implement print preview in deskPDF's way? Thanks.

let's do programming!!

Linking DLL's

joeller6-Nov-06 8:57

6-Nov-06 8:57

I am a long time VB and ASP developer, experienced in both 6.0 and .net. I have had considerable experience in designing COM dll's and .Net class libraries for use by other applications. I am now trying to modularize a complex Visual C++ application by building dll's that can be referenced by different calling applications. Because of the complexity of the code, the short turn aound time and the lack of .Net and COM experience by the other members of the team, this is being done by building a number of Win32 dll's that will then be "plugged into" the calling application.

Therefore, I am trying to implicitly link a dll to an executable project using Visual Studio .Net (2002) Visual C++ 7.0. According to Microsoft, the search path used by Windows with implicit linking is 1. the directory where the executable module for the current process is located, 2. the current Directory, 3. the Windows system directory, 4. the Windows directory, and 5. the directories listed in the Path environment variable.

The documentation for VS 2002 states the "show directories for Executable files" on the "VC++ Directories" property page, lists the directories that Visual Studio will search for executable files and that it corresponds to the PATH environment variable.

I used this property page to link successfully to the library files in the lib directory of the dll project and the header files in the include directory of that project. I used the same means to link to the dll files in the bin directory of that project and I keep getting the "This application has failed to start because yadadyada.dll was not found. Reinstalling the application may fix this problem." message. When I built this application on another machine with VS 2005, the project properties page under Configuration Properties\Debugging had an entry called "Evironment" whereby I could enter the relative path to the YadaYada\bin directory; (Set PATH="..\YadaYada\bin"). But I was not able to find any equivalent entry on the property pages in Visual Studio .Net (2002). I manually added the path to the dll to the machine's "PATH" environment variable but it made no difference. When I copied the dll to the project's folder however everything worked as designed.

In my opinion, it is not good practice to include dll's to third party applications directly in your project's directory, (although I know that .Net managed applications do that with referenced third party namespaces). I am also not comfortable with adding third party dll's directly to the system32 directory. I feel that the calling application should be able to refer to the dll in the third party application's own bin folder. I would appreciate some advice on how to make this happen in Visual C++ if possible.

Thank you in advance for your assistance.

E.R. Joell MCSD MCDBA

Mark Salsbery6-Nov-06 12:45

6-Nov-06 12:45

joeller wrote:
In my opinion, it is not good practice to include dll's to third party applications directly in your project's directory, (although I know that .Net managed applications do that with referenced third party namespaces). I am also not comfortable with adding third party dll's directly to the system32 directory. I feel that the calling application should be able to refer to the dll in the third party application's own bin folder. I would appreciate some advice on how to make this happen in Visual C++ if possible.

Welcome to DLL hell. Even Microsoft calls it that. Smile | :)

Adding the path to the PATH environment variable is the way to do it but I believe you'll need a
full path, not a relative path. It doesn't work the same way as the path settings in the
Visual Studio environment, where paths are put together based on your project paths.

joeller7-Nov-06 3:42

7-Nov-06 3:42

"Adding the path to the PATH environment variable is the way to do it but I believe you'll need a full path, not a relative path."

Quite right which is what I did. no joy.

Mark Salsbery7-Nov-06 5:27

7-Nov-06 5:27

Even after reboot (maybe even just re-logon)?

That's worked since before Windows Smile | :)

joeller7-Nov-06 8:08

7-Nov-06 8:08

yeah

Mark Salsbery7-Nov-06 8:17

7-Nov-06 8:17

You may have seen this already but if not, maybe it will help...
Dynamic-Link Library Search Order[^]

Michael Dunn6-Nov-06 16:14

Michael Dunn

6-Nov-06 16:14

The "directories for executable files" setting has nothing to do with the DLL search path. That dir list is where the IDE will look for executables that get run in your build rules.
You'll need to do one of three things
1. Change the app's code to load DLLs from the bin directory (this will mean changing from implicit loading to using LoadLibrary())
2. Put the DLLs in the same dir as the app.
3. Change the machine's PATH variable and add your bin directory (not reliable, as the user can always change the PATH himself)

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ

joeller7-Nov-06 4:21

7-Nov-06 4:21

From original Post:

"When I built this application on another machine with VS 2005, the project properties page under Configuration Properties\Debugging had an entry called "Evironment" whereby I could enter the relative path to the YadaYada\bin directory; (Set PATH="..\YadaYada\bin")."

I neglected to mentioned that when this was done, everything worked as designed.

"But I was not able to find any equivalent entry on the property pages in Visual Studio .Net (2002). I manually added the path to the dll to the machine's "PATH" environment variable but it made no difference. When I copied the dll to the project's folder however everything worked as designed."

That was the full path to the specified folder.

I tried your #2 and it works. That is what everyone is doing now and I would like to get away from that.

I tried your #3 (see above) and it did not work.

I tried #1 several weeks ago. I don't remember whether it worked or not. As I recall it required the entry of the path to the dll in the code. However I am trying to avoid that because that would necessitate each developer putting the dll project on their machine in the same location for the code to work. In this non-optimum development environment, each developer uses source safe to get latest version and installs the projects in whatever location they so desire. They then use the VC++ Directories property page to set the linkages to the other header and library files that are needed. They have been copying the dlls into the project directory. Since I am only a contractor for this one project I do not want to tell them to revise their way of doing business. So I was trying to find means by which they could access dlls without copying them into the project directory. Of course this is the .Net solution. (Where the dll's for each name space that is referenced in your project is copied to your bin directory.) I never liked that resolution for dll hell because it requires that any new version of a dll (stuff like bug fixes and service packs), now need to be copied to every application that uses it. For very general reusable code,that is used in many places, (like this is going to be,) that means quite a lot of copying and checking.

What about the possibility of using the command line additional options under Configuration\C/C++ folder s of the project property pages?

E.R. Joell MCSD MCDBA

Mark Salsbery7-Nov-06 6:47

7-Nov-06 6:47

joeller wrote:
...this is the .Net solution. (Where the dll's for each name space that is referenced in your project is copied to your bin directory.)

Really? I haven't seen that behavior. Where is this documented?

joeller7-Nov-06 9:11

7-Nov-06 9:11

That was two years ago, I no longer remember were we read it. We were creating an ASP.Net application and we noted that after each build there was a copy of all the dll's we were using in the project's bin directory. We checked in out, and found that this behavior was as designed. Supposedly it was to allieviate the issues of DLL Hell to which the first replier referred to, as the application would always have the the version dll with which that it was compiled to work. The other advantage was that it facilitated the use of XCopy to deploy your application without worrying whether the dll that was needed was registered on the machine to which you were deploying. (The customer liked it because he did not have to register third party dll's on his server.) I found it irritating because I had come from a VB 6.0 background where you only had to set binary compatibility then you could replace the dll without having to re-register it.

I ran a google check before answering this entry. But I was not able to locate the place I read it. Could have been a book. Could have been 4GuysFromRolla. Found an entry in MSDN about referencing assemblies. Found a forum entry from a guy that found out the same thing we did. (He asked the question then posted the answer himself when no one answered him.) I am sorry I can't give you a better answer.

E.R. Joell MCSD MCDBA

Mark Salsbery7-Nov-06 9:33

7-Nov-06 9:33

Cool thanks.

A proper entry in the PATH environment variable should work. It's really strange that it doesn't
work for you.

Mark

joeller7-Nov-06 10:24