WinApi
WinApi copied to clipboard
Clipboard helpers were added #15
Few functions connected to the windows clipboard were added and a wrapper around it.
will update my pull request in the future, please don't merge yet. created it for the sake of knowing what im doing
-
Clipboard
- Can pass IClipboardData
- Can read IClipboardData
- Allows subscribe option(Post event is not implemented)
- Changed samples a bit
- Added a console application sample
Wasn't able to solve my problem with a cancelation token in Clipboard tho, maybe make EventLoop().Run() async? I know it should be wraped in the the using statement, but still.
Issue -> #15
22.06.18 Update:
The Win32Clipboard class was moved into a different PR
@prasannavl any thoughts?
@Trapov, thank you for the PR. Sorry, was a busy week. Had to put this off until the weekend. Will have a look by the weekend.
@prasannavl well, i know it's been a while ago since i opened the PR but i still want it to be merged.
Hi @Trapov, I'm sorry I haven't been able to catch up on this. I've been struggling with some hand surgeries for the last few months, and have been completely off programming. Just slowly easing back in. Unfortunately, I'm still catching up with a lot of the backlog and it may take a while for me to look into the design.
That being said, could you please make a separate PR for the Constants
, and User32/Methods
? That should really be helpful, but they don't really require any design thought.
PS: For future reference, I also suggest making separate PRs for direct Win32 items (Methods, Constants, etc), helpers, and library features. That helps in merging smaller isolated items without delays. :)
@prasannavl sorry to hear that, get better. Ok, will do like you said.
Also the feature is not nearly done, there are still some things that aren't tested and have bad design, i want to hear your opinion on those things, such us: cancellation token, getting an image from the cliboard and etc.
@prasannavl ok, now this PR is solely dedicated to pinvoke/helper-methods and constants. I can make another one with the Win32Clipboard control, but it will depend from this branch, since it will use the clipboard functions, constants and helpers; not really sure if that's a great idea.
Thank you for the response.
And the GetFromClipboard that's just the data again
@prasannavl I would do that, but since GetClipboardData
returns a pointer, i would have to know it exact length/size, to get a byte[] array from that. I could just go thru it and determine where is the end of the array by checking null values, don't really think it's a good idea tho.
Will fix everything else.
Yeah, Clipboard is not a simple API. It's handles a lot of conversions and complexities. In that case, what do you think about just focusing on text instead in the helpers. Just take a string input for SetClipboardUnicodeText
, and GetClipboardUnicodeText
, and use CF_UNICODETEXT for both. And use SetClipboardData
as a raw method that takes a byte array as you've used and uses NULL for the format internally. But leave out the Get part for that until we can come up with a better design. Meanwhile, the User32 function can always be used directly utilising the pointer.
Yeah, sounds good.
Additionally, SetClipboardData could have an overload with the exact format constants.
@prasannavl what do you think about those apis?
This is great, actually :+1:. I like it.
Just thinking out loud here: Would it be better to have TryGetUnicodeTextFromClipboard
as TryGetClipboardUnicodeText
? So it has parity with TrySetClipboardUnicodeText
.
And also has the minor side advantage of getting nice and relevant autocomplete with or without fuzzy matching, when you type TryGetClip
.
@prasannavl, yea that makes sense. Will do.
@prasannavl done. You probably want to squash all my commits, or rebase, because they don't make much sense in the context of your repo history, imho.
@prasannavl, any other problems with the pull request?
@Trapov If you're still active, you should rebase
and push --force-with-lease
. That tends to have a cleaner history across repositories. If prasannavl rebased your branch manually or by using GitHub's "Rebase and Merge Pull Request" feature, then the commit history here will be slightly different than your commit history. This makes tracing commits by their hashes back to their origin a but more difficult.
If there are merge conflicts, then prasannavl's conflict resolutions will likely require a new commit, separate from the merge commit. This is because using a merge commit to store conflict resolutions can lead to those conflict resolutions being lost if merge commits are rebased (--rebase-merges
).