>>>>>>>Anyone know the win api calls to get the data from the clipboard and store it to a variable? I am using VFP5.0 and have looked at _cliptext and getclipdata() in foxtools.fll and none of these return the 'correct' value. The _cliptext seems to strip the chr(13) chr(10) and getclipdata() doesn't seem to do anything(I am using openclip() first).
>>>>>>>
>>>>>>>Let me explain a little more. I make a call to another application(written in C++) that sends me back some information on the clipboard. When I look at the clipboard with clipbrd.exe everything looks fine, when I paste the clipboard text into any other application it pastes fine. But when I look at the text in FoxPro it seems to remove any chr(13) chr(10) information. I need to parse this data and the chr(13) chr(10) characters are the sperators. Any Ideas? Thanks
>>>>>>
>>>>>>Hi Scott,
>>>>>>
>>>>>>I don't think that there's an easy way to do this via the API or foxtools. Is the application that's sending the information via the clipboard setting the format to CF_TEXT? If so, then at least the carriage returns should be in the _CLIPTEXT system variable.
>>>>>>
>>>>>>I would think, however, that using DDE services for this would be a better solution.
>>>>>
>>>>>One alternative to examine is to create an ActiveX control to process the clipboard content and present the whole thing to VFP; this is an approach I worked with for one client that needed to pull formatting data (only boldfaced text) from an Excel spreadsheet via the clipboard. I didn't write the code myself (it was written in VB6) but it was less than a dozen lines of code to pull all data types from the clipboard and present them to VFP via a collection.
>>>>
>>>>Hi Ed,
>>>>
>>>>Yep! That's another way of doing it. My thought, however, was that since DDE sends values to VFP as CF_TEXT (the format desired), it would be a simple, and relatively straight forward way of doing it.
>>>
>>>Assuming that the other app supports DDE...not always a given. Or are you suggesting a DDE conversation with something other than the C++ app?
>>
>>It was my understanding that the app was written in C++. That's why I made the suggestion.
>
>The app would still have to be written to support a DDE conversation, regardless of the language it was written in...

Yep, no doubt about it. It just seemed to be the easiest method of implementing what I think the requirements are.