I've been playing around with the windows clipboard. I noticed that you can only view the clipboard if you supply a format. I've seen programs that can dump the raw contents of the clipboard. Look at http://www.autohotkey.com/docs/misc/Clipboard.htm#ClipboardAll for an example of what I mean.
Is there a way to do something similar, what I want to do is be able to back up the clipboard, manipulate it, then restore it when my program is done.
I'm looking for a non-.net solution if that's actually a thing
EDIT:
I tried this so far:
struct clipData {
vector<void*> data;
vector<int> size;
};
struct clipData saveClipboard(int &size) {
clipData ret;
UINT currentFormat = 0;
HGLOBAL hData;
if (OpenClipboard(0)) {
while(currentFormat = EnumClipboardFormats(currentFormat)) {
hData = GetClipboardData(currentFormat);
int currentClipboardFormatSize = GlobalSize(hData); //Only works with text formats. Help!
char *savedClipboardData = new char[currentClipboardFormatSize];
char *ptrToData = (char*) GlobalLock(hData);
memcpy(savedClipboardData, ptrToData, currentClipboardFormatSize);
ret.data.push_back(savedClipboardData);
ret.size.push_back(currentClipboardFormatSize);
}
CloseClipboard();
}
return ret;
}
But the problem is theres no way to tell how big the clipboard is in each format
There's no "raw" data involved. Just enumerate all the formats currently on the clipboard, and fetch and save the contents of each format. But be careful of automatic format conversions.
If you carefully read the autohotkey documentation you linked, it even tells you that it's retrieving each format separately, and that it may only succeed in retrieving a subset of the formats.
MSDN has all the examples you need to know to manipulate clipboard data using Clipboard API.
Related
I have an ID3D11Texture2D. The end goal is to take the image and embed it into html as a base64 encoded string (requirements are based on existing functionality of which I have no control). I can achieve this by saving the texture to file using DirectX::SaveWICTextureToFile, loading the texture as a byte array, then encoding the array in base64, but I'd like to do it without saving to a file if possible.
Ideally there would be some kind of SaveWICTextureToMemory function that can take the container format as a parameter, but so far I haven't found anything that deals with the format. I've checked out CreateWICTextureFromMemory and other functions in the WICTextureLoader package, but I didn't find exactly what I'm looking for (perhaps I missed it). Figuring SaveWICTextureToFile must generate a byte array to write to file, I tried to essentially unpack that function and strip away the file creation elements of it, but decided there was likely a simpler solution, which brought me here.
I don't have much code to look at, as I've only stubbed out many of the key functions, but this is generally where this stuff needs to live:
HRESULT ExportImages::GetAngleEncodedString(std::string& encoded, const DirectX::XMMATRIX& projectionMatrix, float radians) const
{
// Draws geometry to m_Texture2D
DrawAngle(projectionMatrix, radians);
unsigned const char* pngBytes = GetPNGBytes(m_Texture2D);
try
{
encoded = Base64Encode(pngBytes);
}
catch (...)
{
// TODO don't catch all, add resolution
return HRESULT(-1);
}
return S_OK;
}
unsigned const char* ExportImages::GetPNGBytes(ID3D11Texture2D* texture) const
{
// ???
}
I am trying to create custom tcl channel and use it to get the output of tcl Interpreter. I added the implementation of few function of Tcl_ChannelType but I am getting segfault.
#include <tcl.h>
#include <iostream>
int driverBlockModeProc(ClientData instanceData, int mode) {
std::cout << "driverBlockModeProc\n";
return 0;
}
int driverCloseProc(ClientData instanceData, Tcl_Interp *interp) {
std::cout << "driverCloseProc\n";
return 0;
}
int driverInputProc(ClientData instanceData, char* buf, int bufSize, int *errorCodePtr) {
std::cout << "driverInputProc\n";
return 0;
}
int driverOutputProc(ClientData instanceData, const char* buf, int toWrite, int *errorCodePtr) {
std::cout << "driverOutputProc\n";
return 0;
}
int main() {
Tcl_ChannelType *typePtr = new Tcl_ChannelType;
typePtr->blockModeProc = driverBlockModeProc;
typePtr->outputProc = driverOutputProc;
typePtr->closeProc = driverCloseProc;
typePtr->inputProc = driverInputProc;
typePtr->seekProc = NULL;
typePtr->setOptionProc = NULL;
typePtr->getOptionProc = NULL;
typePtr->watchProc = NULL;
typePtr->getHandleProc = NULL;
typePtr->close2Proc = NULL;
typePtr->blockModeProc = NULL;
typePtr->flushProc = NULL;
typePtr->handlerProc = NULL;
typePtr->wideSeekProc = NULL;
typePtr->threadActionProc = NULL;
ClientData data = new char[200];
Tcl_CreateChannel(typePtr, "im_chanel", data, TCL_WRITABLE | TCL_READABLE);
}
I cant debug the segfault because its source are not available. I think the segfault is because a function is called which is NULL. I only need to use the channel to get the output of interpreter. Which functions I needn't implement here and is it right direction to solve the problem.
You're advised to download the source to Tcl when working at this level. I'm not sure what version you're using, but all official distributions of the source going back a very long way are on the SourceForge file distribution system; pick the exact match for the version you've got.
Creating a custom channel driver is not easy. There's a significant amount of complexity involved, and it isn't especially well-documented what “methods” within the channel driver type are mandatory and what are optional. (They're not C++ methods in a class — Tcl is pure C code for reasons too long to go into here — but they function in a conceptually similar way.)
If we look at the documentation for Tcl_CreateChannel, we see (quite a long way down that page) a definition of the channel type structure. The channel type structure should be statically allocated (Tcl's implementation assumes very strongly that it never changes location) and the following fields must be set to something meaningful:
typeName — This is the name of the channel type, useful for debugging!
version — This is the version of the channel type; you should set it to the latest version supported by your target source level. (You're recommended to use at least TCL_CHANNEL_VERSION_2 or things get rather more complex.)
closeProc or close2Proc — Channels must be closeable, but you have two choices for ways to do it. Bidirectional channels ought to use the close2Proc, but aren't strictly required to.
inputProc — Only needed if you're reading; take care to handle this correctly.
outputProc — Only needed if you're writing; take care to handle this correctly.
watchProc — Called to tell the channel driver to install itself into the event system so as to receive suitable events (as instructed by the supplied bitmask). Channels that don't have backing OS handles use timer events, or simply never actually generate events (in which case they'll never become readable or writable from the perspective of fileevent).
Looking at your code, I see that you're missing a watchProc. I know it's hard to see (not many people write channel drivers, to be honest, so the documentation isn't very hard “tested”) but it's really necessary.
I used to be a C++ expert a decade ago, but for the past 10 years I've been programming Java. I just started a C++ project that uses a small third-party XML parser. The XML parser accepts an STL istream. My XML data is coming from a Windows COM IStream. I thought I'd do the Right Thing and create an adapter to take the IStream data and present it to the XML parser through an istream.
I followed the excellent tutorial at http://www.mr-edd.co.uk/blog/beginners_guide_streambuf and created a COMStreambuf that takes data from the underlying COM IStream, and used it as a buffer for a custom COMIstream. Everything looks good, but I get a read error from the parser.
Turns out the parser reads the whole file into memory by using seekg() on the istream to find out its size and then goes back to the beginning with seekg() to read it in one go. Unsurprisingly, the aforementioned tutorial decided to "save [instructions on implementing seeking] for another post" which was apparently never written.
Can someone tell me what I need to do to implement seekg() with my custom istream/streambuf? I would venture out doing it myself (my first inclination would be to override stuff in istream), but with my inexperience this deep in the STL and with my Java mentality I fear I would do something incomplete and have a brittle solution. (Without reading tutorials, for example, I never would have guessed that one makes a custom istream by writing a new streambuf, for example, or that I would need to call imbue() with a default locale, etc.)
Thanks for any help. I've been very impressed with this site---both with the knowledge of the participants and their friendly, honest nature in conceding who has the best answer. :)
I assume that by "seekg" you mean seekoff and seekpos.
The straightforward way to implement members seekoff and seekpos of your COMStreambuf is to wrap the Seek method of the IStream interface. For example, something like this should work:
// COMStreambuf.cpp
COMStreambuf::pos_type COMStreambuf::seekoff(COMStreambuf::off_type off_, std::ios_base::seekdir way_, std::ios_base::openmode which_)
{
union {
LARGE_INTEGER liMove;
ULARGE_INTEGER uliMove;
};
liMove.QuadPart = off_;
DWORD dwOrigin = STREAM_SEEK_SET;
if (way_ == std::ios_base::cur) {
dwOrigin = STREAM_SEEK_CUR;
} else if (way_ == std::ios_base::end) {
dwOrigin = STREAM_SEEK_END;
} else {
assert(way_ == std::ios_base::beg);
dwOrigin = STREAM_SEEK_SET;
uliMove.QuadPart = off_;
}
ULARGE_INTEGER uliNewPosition;
if (which_ & std::ios_base::in) {
if (which_ & std::ios_base::out)
return pos_type(off_type(-1));
HRESULT hres = streamIn->Seek(liMove, dwOrigin, &uliNewPosition);
if (hres != S_OK)
return pos_type(off_type(-1));
setg(eback(), egptr(), egptr());
} else if (which_ & std::ios_base::out) {
HRESULT hres = streamOut->Seek(liMove, dwOrigin, &uliNewPosition);
if (hres != S_OK)
return pos_type(off_type(-1));
setp(pbase(), epptr(), epptr());
} else {
return pos_type(off_type(-1));
}
return pos_type(uliNewPosition.QuadPart);
}
COMStreambuf::pos_type COMStreambuf::seekpos(COMStreambuf::pos_type sp_, std::ios_base::openmode which_)
{
return seekoff(off_type(sp_), std::ios_base::beg, which_);
}
In this listing, after setting the position of streamIn I call:
setg(eback(), egptr(), egptr());
After a seek, sputbackc or sungetc will operate on old data. You may want to consider whether this makes sense for your application and do something different.
this question may seem a bit too specific, but I figure I'd give it a shot here since I've found some great programming answers here in the past.
I am modifying the open-source program TinyCad for a project I'm working on. I've visited the TinyCad message board and posted, but I didn't get the answer I'm looking for. I'm having trouble wrapping my head about how to integrate a small XML converter class I wrote into the loading function of TinyCad.
A little background about me: I have no experience with MFC or Visual Studio, but that is what I have to use. I am used to C++ and was taught using iostream syntax (cout, cin, new, etc.) so I'm not used to older C code (like printf, sprintf, malloc, alloc, etc.) either. I usually write my programs from start to finish in Qt, but I was told that for this project I should modify an existing program to save time. I don't know if it'll save that much time if I have to learn something totally foreign, but I digress.
I wrote a small class to read in an XML file that is structured differently than the XML file that TinyCad reads in. My class converts it and outputs an intermediate XML file. Well, I don't want to spit out an intermediate file. I modified it to save the output as a string (using the string datatype from the standard C++ iostream library). I want to get this string into a stream so that TinyCad can open the file, do the conversion, and then continue loading.
My class is called like so:
std::string blah;
char* filename = "library.xml";
XMLopen myXML(filename, blah);
So it takes in a filename, opens the file, parses the relevant information out of the file, puts the information into TinyCad's XML structure, and saves the XML code as a string that has been passed by reference.
I had an idea to use istringstream to make a stream, but that did not play nice with CFile. I tried it like so:
istringstream ins; // Declare an input string stream.
ins.str(blah);
// First open the stream to save to
CFile theFile(ins);
Below is the code in TinyCad that opens and loads the selected XML file:
void CLibraryStore::LoadXML( const TCHAR *filename )
{
// First open the stream to save to
CFile theFile;
// Open the file for saving as a CFile for a CArchive
BOOL r = theFile.Open(filename, CFile::modeRead);
if (r)
{
CString name;
// Create the XML stream writer
CStreamFile stream( &theFile, CArchive::load );
CXMLReader xml( &stream );
// Get the library tag
xml.nextTag( name );
if (name != "Library")
{
Message(IDS_ABORTVERSION,MB_ICONEXCLAMATION);
return;
}
xml.intoTag();
CTinyCadApp::SetLockOutSymbolRedraw( true );
while ( xml.nextTag( name ) )
{
// Is this a symbol?
if (name == "SYMBOL")
{
// Load in the details
xml.intoTag();
CTinyCadMultiSymbolDoc temp_doc;
drawingCollection drawing;
CLibraryStoreNameSet s;
// this is where the stream gets sent to be loaded into the data structure
s.LoadXML( &temp_doc, xml );
xml.outofTag();
// ... and store the symbol
Store( &s, temp_doc );
}
}
xml.outofTag();
CTinyCadApp::SetLockOutSymbolRedraw( false );
}
}
Edit 7/28/2010 5:55PM
So I tried to make a stream, but it fails.
CStreamFile takes in a filename and then gets set as a CArchive:
m_pArchive = new CArchive( theFile, nmode );
I tried to make a CStream like so (since CStreamFile is an overloaded CStream):
CString test = blah.c_str();
CStreamMemory streamCS;
streamCS << test;
CXMLReader xml( &streamCS );
But at streamCS << test; it doesn't put the stream in at all. test gets assigned correctly with blah so I know that's working.
Any ideas on how to approach this?
I'm creating an IStream as follow:
IStream* stream;
result = CreateStreamOnHGlobal(0, TRUE, &stream);
Then I have a CImage object that I save to this stream:
image->Save(stream, Gdiplus::ImageFormatBMP);
I need to get the size of bytes written to this IStream.
How can I do this?
There is no Length or something like this in the IStream...
thanks!
IStream::Stat should do what you want.
Or you can use:
ULARGE_INTEGER liSize;
IStream_Size(pStream, &liSize);
other functions you might find useful in this context:
IStream_Reset(pStream); // reset seek position to beginning
IStream_Read(pStream, mem, size);
Both IStream_Size as well as IStream::Stat can be used to request the size. IStream_Size appears to be a convenience wrapper around IStream::Stat (that's oddly only available as a C COM macro). If that is indeed the case then there's a lot of data queried: An entire STATSTG, optionally without the pwcsName member.
In that case, a less costly way to get the same information would be IStream::Seek:
HRESULT get_size(IStream* stream, ULARGE_INTEGER& size) {
return IStream->Seek({}, STREAM_SEEK_END, &size);
}
This changes the stream's current read or write pointer. If you need to save the current position you can use the following:
ULARGE_INTEGER current{};
stream->Seek({}, STREAM_SEEK_CUR, ¤t);