DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 9 of 9

Thread: Excessive occurences of WM_DRAWCLIPBOARD messages

  1. #1
    Valentin Bakhov Guest

    Excessive occurences of WM_DRAWCLIPBOARD messages

    Hi, All!

    The problem: double occurences of WM_DRAWCLIPBOARD for the same Clipboard
    contents.

    To repicate this situation, download Karl Peterson's ClipView from
    http://www.mvps.org/vb/code/ClipView.zip .
    Load it in IDE and insert Debug.Print "WM_CHANGECBCHAIN" and Debug.Print
    "WM_DRAWCLIPBOARD" in Form subclassing.
    Start MS Photo Editor (or some other picture viewer) with some jpg-file.
    Start ClipView.
    I believe you'll get the following (the same I've got):
    (1) WM_DRAWCLIPBOARD message (No.0) on load - which is normal as ClipView
    gets
    in clipboard viewchain
    (2) click right button on picture in PhotoEd and choose Copy command -
    you'll get 1st (normal) WM_DRAWCLIPBOARD, just as Karl intended
    (3) close PhotoEd - you'll get 2nd WM_DRAWCLIPBOARD, excessive. Similar
    things
    occur while drag copy/move in MS Office (Outlook, Excel) and in good many
    other progs.
    BTW, no WM_CHANGECBCHAIN's, as PhotoEd is higher than ClipView in viewchain.

    One way to avoid second messages (my app stores Clipboard by
    WM_DRAWCLIPBOARD's)
    is to clear Clipboard - not so polite to the user; another one is to
    calculate
    CRC32 which means tangible delay while copying big pictures. Is there some
    decent method doing things - to determine that WM_DRAWCLIPBOARD repeats by
    reason of program termination or something?

    I'd appreciate copying replies (if any) to my e-mail address.

    Thanks in advance,
    Valentin




  2. #2
    Karl E. Peterson Guest

    Re: Excessive occurences of WM_DRAWCLIPBOARD messages

    Hi Valentin --

    Boy, I have no idea, here. The best I can offer is that it's likely these apps are
    using the clipboard behind your back, then restoring it to a previous condition, all
    too quickly for you to notice.

    Sorry... Karl
    --
    http://www.mvps.org/vb


    "Valentin Bakhov" <v.bakhov@globalone.ru> wrote in message
    news:3b13818f@news.devx.com...
    > Hi, All!
    >
    > The problem: double occurences of WM_DRAWCLIPBOARD for the same Clipboard
    > contents.
    >
    > To repicate this situation, download Karl Peterson's ClipView from
    > http://www.mvps.org/vb/code/ClipView.zip .
    > Load it in IDE and insert Debug.Print "WM_CHANGECBCHAIN" and Debug.Print
    > "WM_DRAWCLIPBOARD" in Form subclassing.
    > Start MS Photo Editor (or some other picture viewer) with some jpg-file.
    > Start ClipView.
    > I believe you'll get the following (the same I've got):
    > (1) WM_DRAWCLIPBOARD message (No.0) on load - which is normal as ClipView
    > gets
    > in clipboard viewchain
    > (2) click right button on picture in PhotoEd and choose Copy command -
    > you'll get 1st (normal) WM_DRAWCLIPBOARD, just as Karl intended
    > (3) close PhotoEd - you'll get 2nd WM_DRAWCLIPBOARD, excessive. Similar
    > things
    > occur while drag copy/move in MS Office (Outlook, Excel) and in good many
    > other progs.
    > BTW, no WM_CHANGECBCHAIN's, as PhotoEd is higher than ClipView in viewchain.
    >
    > One way to avoid second messages (my app stores Clipboard by
    > WM_DRAWCLIPBOARD's)
    > is to clear Clipboard - not so polite to the user; another one is to
    > calculate
    > CRC32 which means tangible delay while copying big pictures. Is there some
    > decent method doing things - to determine that WM_DRAWCLIPBOARD repeats by
    > reason of program termination or something?
    >
    > I'd appreciate copying replies (if any) to my e-mail address.
    >
    > Thanks in advance,
    > Valentin
    >
    >
    >



  3. #3
    Karl E. Peterson Guest

    Re: Excessive occurences of WM_DRAWCLIPBOARD messages

    Hi Valentin --

    Boy, I have no idea, here. The best I can offer is that it's likely these apps are
    using the clipboard behind your back, then restoring it to a previous condition, all
    too quickly for you to notice.

    Sorry... Karl
    --
    http://www.mvps.org/vb


    "Valentin Bakhov" <v.bakhov@globalone.ru> wrote in message
    news:3b13818f@news.devx.com...
    > Hi, All!
    >
    > The problem: double occurences of WM_DRAWCLIPBOARD for the same Clipboard
    > contents.
    >
    > To repicate this situation, download Karl Peterson's ClipView from
    > http://www.mvps.org/vb/code/ClipView.zip .
    > Load it in IDE and insert Debug.Print "WM_CHANGECBCHAIN" and Debug.Print
    > "WM_DRAWCLIPBOARD" in Form subclassing.
    > Start MS Photo Editor (or some other picture viewer) with some jpg-file.
    > Start ClipView.
    > I believe you'll get the following (the same I've got):
    > (1) WM_DRAWCLIPBOARD message (No.0) on load - which is normal as ClipView
    > gets
    > in clipboard viewchain
    > (2) click right button on picture in PhotoEd and choose Copy command -
    > you'll get 1st (normal) WM_DRAWCLIPBOARD, just as Karl intended
    > (3) close PhotoEd - you'll get 2nd WM_DRAWCLIPBOARD, excessive. Similar
    > things
    > occur while drag copy/move in MS Office (Outlook, Excel) and in good many
    > other progs.
    > BTW, no WM_CHANGECBCHAIN's, as PhotoEd is higher than ClipView in viewchain.
    >
    > One way to avoid second messages (my app stores Clipboard by
    > WM_DRAWCLIPBOARD's)
    > is to clear Clipboard - not so polite to the user; another one is to
    > calculate
    > CRC32 which means tangible delay while copying big pictures. Is there some
    > decent method doing things - to determine that WM_DRAWCLIPBOARD repeats by
    > reason of program termination or something?
    >
    > I'd appreciate copying replies (if any) to my e-mail address.
    >
    > Thanks in advance,
    > Valentin
    >
    >
    >



  4. #4
    Valentin Bakhov Guest

    Re: Excessive occurences of WM_DRAWCLIPBOARD messages

    Hi, Karl,

    1st, personal thanks for your site and codes in it - have been good help for
    me in my weekend programming! Now to Clipboard. It seems that this phenom
    often occurs on app's closing. Just now I've tried MS Outlook 2000 and
    Outlook Express 5.0. In MSOL it occurs in each note - open a note, copy a
    part, close and here you are - 2 Clipboard messages. It's not so if you open
    a letter (a possible explanation is that a note is an app in its own right).
    In OE opening a letter etc. produces only one, but closing OE immediately
    gives a duplicate of last piece copied. On the other hand, Acrobat Reader
    4.0 gives 4 DRAWCB's (!) on each copy op and none on closing. ACDsee 2.3
    (freeware pic viewer) works OK. (This time all experimenting is in my app -
    in which I corrected copy clipboard module acc.to your code referenced, but
    the same thing persisted - I mean I noticed it rather long ago, but thought
    it was my faulty coding.)

    Sorry for being obtrusive, but I have a feeling that an answer is near -
    only I haven't enough knowledge of WIndows internals (written in C++) to get
    my hands on it. Would be fine if someone could try it on your ClipView and
    at least say that this story with duplicates is true - or false.

    Best regards,
    Valentin

    Karl E. Peterson <karl@mvps.org> wrote in message
    news:3b140ae3$1@news.devx.com...
    > Hi Valentin --
    >
    > Boy, I have no idea, here. The best I can offer is that it's likely these

    apps are
    > using the clipboard behind your back, then restoring it to a previous

    condition, all
    > too quickly for you to notice.
    >
    > Sorry... Karl
    > --
    > http://www.mvps.org/vb
    >
    >
    > "Valentin Bakhov" <v.bakhov@globalone.ru> wrote in message
    > news:3b13818f@news.devx.com...
    > > Hi, All!
    > >
    > > The problem: double occurences of WM_DRAWCLIPBOARD for the same

    Clipboard
    > > contents.
    > >
    > > To repicate this situation, download Karl Peterson's ClipView from
    > > http://www.mvps.org/vb/code/ClipView.zip .
    > > Load it in IDE and insert Debug.Print "WM_CHANGECBCHAIN" and Debug.Print
    > > "WM_DRAWCLIPBOARD" in Form subclassing.
    > > Start MS Photo Editor (or some other picture viewer) with some jpg-file.
    > > Start ClipView.
    > > I believe you'll get the following (the same I've got):
    > > (1) WM_DRAWCLIPBOARD message (No.0) on load - which is normal as

    ClipView
    > > gets
    > > in clipboard viewchain
    > > (2) click right button on picture in PhotoEd and choose Copy command -
    > > you'll get 1st (normal) WM_DRAWCLIPBOARD, just as Karl intended
    > > (3) close PhotoEd - you'll get 2nd WM_DRAWCLIPBOARD, excessive. Similar
    > > things
    > > occur while drag copy/move in MS Office (Outlook, Excel) and in good

    many
    > > other progs.
    > > BTW, no WM_CHANGECBCHAIN's, as PhotoEd is higher than ClipView in

    viewchain.
    > >
    > > One way to avoid second messages (my app stores Clipboard by
    > > WM_DRAWCLIPBOARD's)
    > > is to clear Clipboard - not so polite to the user; another one is to
    > > calculate
    > > CRC32 which means tangible delay while copying big pictures. Is there

    some
    > > decent method doing things - to determine that WM_DRAWCLIPBOARD repeats

    by
    > > reason of program termination or something?
    > >
    > > I'd appreciate copying replies (if any) to my e-mail address.
    > >
    > > Thanks in advance,
    > > Valentin
    > >
    > >
    > >

    >



  5. #5
    Valentin Bakhov Guest

    Re: Excessive occurences of WM_DRAWCLIPBOARD messages

    Hi, Karl,

    1st, personal thanks for your site and codes in it - have been good help for
    me in my weekend programming! Now to Clipboard. It seems that this phenom
    often occurs on app's closing. Just now I've tried MS Outlook 2000 and
    Outlook Express 5.0. In MSOL it occurs in each note - open a note, copy a
    part, close and here you are - 2 Clipboard messages. It's not so if you open
    a letter (a possible explanation is that a note is an app in its own right).
    In OE opening a letter etc. produces only one, but closing OE immediately
    gives a duplicate of last piece copied. On the other hand, Acrobat Reader
    4.0 gives 4 DRAWCB's (!) on each copy op and none on closing. ACDsee 2.3
    (freeware pic viewer) works OK. (This time all experimenting is in my app -
    in which I corrected copy clipboard module acc.to your code referenced, but
    the same thing persisted - I mean I noticed it rather long ago, but thought
    it was my faulty coding.)

    Sorry for being obtrusive, but I have a feeling that an answer is near -
    only I haven't enough knowledge of WIndows internals (written in C++) to get
    my hands on it. Would be fine if someone could try it on your ClipView and
    at least say that this story with duplicates is true - or false.

    Best regards,
    Valentin

    Karl E. Peterson <karl@mvps.org> wrote in message
    news:3b140ae3$1@news.devx.com...
    > Hi Valentin --
    >
    > Boy, I have no idea, here. The best I can offer is that it's likely these

    apps are
    > using the clipboard behind your back, then restoring it to a previous

    condition, all
    > too quickly for you to notice.
    >
    > Sorry... Karl
    > --
    > http://www.mvps.org/vb
    >
    >
    > "Valentin Bakhov" <v.bakhov@globalone.ru> wrote in message
    > news:3b13818f@news.devx.com...
    > > Hi, All!
    > >
    > > The problem: double occurences of WM_DRAWCLIPBOARD for the same

    Clipboard
    > > contents.
    > >
    > > To repicate this situation, download Karl Peterson's ClipView from
    > > http://www.mvps.org/vb/code/ClipView.zip .
    > > Load it in IDE and insert Debug.Print "WM_CHANGECBCHAIN" and Debug.Print
    > > "WM_DRAWCLIPBOARD" in Form subclassing.
    > > Start MS Photo Editor (or some other picture viewer) with some jpg-file.
    > > Start ClipView.
    > > I believe you'll get the following (the same I've got):
    > > (1) WM_DRAWCLIPBOARD message (No.0) on load - which is normal as

    ClipView
    > > gets
    > > in clipboard viewchain
    > > (2) click right button on picture in PhotoEd and choose Copy command -
    > > you'll get 1st (normal) WM_DRAWCLIPBOARD, just as Karl intended
    > > (3) close PhotoEd - you'll get 2nd WM_DRAWCLIPBOARD, excessive. Similar
    > > things
    > > occur while drag copy/move in MS Office (Outlook, Excel) and in good

    many
    > > other progs.
    > > BTW, no WM_CHANGECBCHAIN's, as PhotoEd is higher than ClipView in

    viewchain.
    > >
    > > One way to avoid second messages (my app stores Clipboard by
    > > WM_DRAWCLIPBOARD's)
    > > is to clear Clipboard - not so polite to the user; another one is to
    > > calculate
    > > CRC32 which means tangible delay while copying big pictures. Is there

    some
    > > decent method doing things - to determine that WM_DRAWCLIPBOARD repeats

    by
    > > reason of program termination or something?
    > >
    > > I'd appreciate copying replies (if any) to my e-mail address.
    > >
    > > Thanks in advance,
    > > Valentin
    > >
    > >
    > >

    >



  6. #6
    Karl E. Peterson Guest

    Re: Excessive occurences of WM_DRAWCLIPBOARD messages

    Hi Valentin --

    Yes, I've repro'd what you're talking about here, too. As I suggested, I do think
    it's something going on behind the scenes, in how these apps are using the clipboard
    internally. You might be able to deduce what's up with some wild experimentations,
    perhaps using the ClipEx.zip sample from my site as a starting point?

    For example, the acrobat issue you mention causes me to think they're calling
    OpenClipboard/CloseClipboard for each format they put on it, rather than just once?
    That would be something to test. Try putting multiple items on the clipboard in
    different ways, and observe what messages are generated.

    What you're seeing is just too inconsistent to be something other than uniquely tied
    to the internals of the apps you're using, I'm afraid.

    Later... Karl
    --
    http://www.mvps.org/vb


    "Valentin Bakhov" <v.bakhov@globalone.ru> wrote in message
    news:3b14c74a$1@news.devx.com...
    > Hi, Karl,
    >
    > 1st, personal thanks for your site and codes in it - have been good help for
    > me in my weekend programming! Now to Clipboard. It seems that this phenom
    > often occurs on app's closing. Just now I've tried MS Outlook 2000 and
    > Outlook Express 5.0. In MSOL it occurs in each note - open a note, copy a
    > part, close and here you are - 2 Clipboard messages. It's not so if you open
    > a letter (a possible explanation is that a note is an app in its own right).
    > In OE opening a letter etc. produces only one, but closing OE immediately
    > gives a duplicate of last piece copied. On the other hand, Acrobat Reader
    > 4.0 gives 4 DRAWCB's (!) on each copy op and none on closing. ACDsee 2.3
    > (freeware pic viewer) works OK. (This time all experimenting is in my app -
    > in which I corrected copy clipboard module acc.to your code referenced, but
    > the same thing persisted - I mean I noticed it rather long ago, but thought
    > it was my faulty coding.)
    >
    > Sorry for being obtrusive, but I have a feeling that an answer is near -
    > only I haven't enough knowledge of WIndows internals (written in C++) to get
    > my hands on it. Would be fine if someone could try it on your ClipView and
    > at least say that this story with duplicates is true - or false.
    >
    > Best regards,
    > Valentin
    >
    > Karl E. Peterson <karl@mvps.org> wrote in message
    > news:3b140ae3$1@news.devx.com...
    > > Hi Valentin --
    > >
    > > Boy, I have no idea, here. The best I can offer is that it's likely these

    > apps are
    > > using the clipboard behind your back, then restoring it to a previous

    > condition, all
    > > too quickly for you to notice.
    > >
    > > Sorry... Karl
    > > --
    > > http://www.mvps.org/vb
    > >
    > >
    > > "Valentin Bakhov" <v.bakhov@globalone.ru> wrote in message
    > > news:3b13818f@news.devx.com...
    > > > Hi, All!
    > > >
    > > > The problem: double occurences of WM_DRAWCLIPBOARD for the same

    > Clipboard
    > > > contents.
    > > >
    > > > To repicate this situation, download Karl Peterson's ClipView from
    > > > http://www.mvps.org/vb/code/ClipView.zip .
    > > > Load it in IDE and insert Debug.Print "WM_CHANGECBCHAIN" and Debug.Print
    > > > "WM_DRAWCLIPBOARD" in Form subclassing.
    > > > Start MS Photo Editor (or some other picture viewer) with some jpg-file.
    > > > Start ClipView.
    > > > I believe you'll get the following (the same I've got):
    > > > (1) WM_DRAWCLIPBOARD message (No.0) on load - which is normal as

    > ClipView
    > > > gets
    > > > in clipboard viewchain
    > > > (2) click right button on picture in PhotoEd and choose Copy command -
    > > > you'll get 1st (normal) WM_DRAWCLIPBOARD, just as Karl intended
    > > > (3) close PhotoEd - you'll get 2nd WM_DRAWCLIPBOARD, excessive. Similar
    > > > things
    > > > occur while drag copy/move in MS Office (Outlook, Excel) and in good

    > many
    > > > other progs.
    > > > BTW, no WM_CHANGECBCHAIN's, as PhotoEd is higher than ClipView in

    > viewchain.
    > > >
    > > > One way to avoid second messages (my app stores Clipboard by
    > > > WM_DRAWCLIPBOARD's)
    > > > is to clear Clipboard - not so polite to the user; another one is to
    > > > calculate
    > > > CRC32 which means tangible delay while copying big pictures. Is there

    > some
    > > > decent method doing things - to determine that WM_DRAWCLIPBOARD repeats

    > by
    > > > reason of program termination or something?
    > > >
    > > > I'd appreciate copying replies (if any) to my e-mail address.
    > > >
    > > > Thanks in advance,
    > > > Valentin
    > > >
    > > >
    > > >

    > >

    >



  7. #7
    Karl E. Peterson Guest

    Re: Excessive occurences of WM_DRAWCLIPBOARD messages

    Hi Valentin --

    Yes, I've repro'd what you're talking about here, too. As I suggested, I do think
    it's something going on behind the scenes, in how these apps are using the clipboard
    internally. You might be able to deduce what's up with some wild experimentations,
    perhaps using the ClipEx.zip sample from my site as a starting point?

    For example, the acrobat issue you mention causes me to think they're calling
    OpenClipboard/CloseClipboard for each format they put on it, rather than just once?
    That would be something to test. Try putting multiple items on the clipboard in
    different ways, and observe what messages are generated.

    What you're seeing is just too inconsistent to be something other than uniquely tied
    to the internals of the apps you're using, I'm afraid.

    Later... Karl
    --
    http://www.mvps.org/vb


    "Valentin Bakhov" <v.bakhov@globalone.ru> wrote in message
    news:3b14c74a$1@news.devx.com...
    > Hi, Karl,
    >
    > 1st, personal thanks for your site and codes in it - have been good help for
    > me in my weekend programming! Now to Clipboard. It seems that this phenom
    > often occurs on app's closing. Just now I've tried MS Outlook 2000 and
    > Outlook Express 5.0. In MSOL it occurs in each note - open a note, copy a
    > part, close and here you are - 2 Clipboard messages. It's not so if you open
    > a letter (a possible explanation is that a note is an app in its own right).
    > In OE opening a letter etc. produces only one, but closing OE immediately
    > gives a duplicate of last piece copied. On the other hand, Acrobat Reader
    > 4.0 gives 4 DRAWCB's (!) on each copy op and none on closing. ACDsee 2.3
    > (freeware pic viewer) works OK. (This time all experimenting is in my app -
    > in which I corrected copy clipboard module acc.to your code referenced, but
    > the same thing persisted - I mean I noticed it rather long ago, but thought
    > it was my faulty coding.)
    >
    > Sorry for being obtrusive, but I have a feeling that an answer is near -
    > only I haven't enough knowledge of WIndows internals (written in C++) to get
    > my hands on it. Would be fine if someone could try it on your ClipView and
    > at least say that this story with duplicates is true - or false.
    >
    > Best regards,
    > Valentin
    >
    > Karl E. Peterson <karl@mvps.org> wrote in message
    > news:3b140ae3$1@news.devx.com...
    > > Hi Valentin --
    > >
    > > Boy, I have no idea, here. The best I can offer is that it's likely these

    > apps are
    > > using the clipboard behind your back, then restoring it to a previous

    > condition, all
    > > too quickly for you to notice.
    > >
    > > Sorry... Karl
    > > --
    > > http://www.mvps.org/vb
    > >
    > >
    > > "Valentin Bakhov" <v.bakhov@globalone.ru> wrote in message
    > > news:3b13818f@news.devx.com...
    > > > Hi, All!
    > > >
    > > > The problem: double occurences of WM_DRAWCLIPBOARD for the same

    > Clipboard
    > > > contents.
    > > >
    > > > To repicate this situation, download Karl Peterson's ClipView from
    > > > http://www.mvps.org/vb/code/ClipView.zip .
    > > > Load it in IDE and insert Debug.Print "WM_CHANGECBCHAIN" and Debug.Print
    > > > "WM_DRAWCLIPBOARD" in Form subclassing.
    > > > Start MS Photo Editor (or some other picture viewer) with some jpg-file.
    > > > Start ClipView.
    > > > I believe you'll get the following (the same I've got):
    > > > (1) WM_DRAWCLIPBOARD message (No.0) on load - which is normal as

    > ClipView
    > > > gets
    > > > in clipboard viewchain
    > > > (2) click right button on picture in PhotoEd and choose Copy command -
    > > > you'll get 1st (normal) WM_DRAWCLIPBOARD, just as Karl intended
    > > > (3) close PhotoEd - you'll get 2nd WM_DRAWCLIPBOARD, excessive. Similar
    > > > things
    > > > occur while drag copy/move in MS Office (Outlook, Excel) and in good

    > many
    > > > other progs.
    > > > BTW, no WM_CHANGECBCHAIN's, as PhotoEd is higher than ClipView in

    > viewchain.
    > > >
    > > > One way to avoid second messages (my app stores Clipboard by
    > > > WM_DRAWCLIPBOARD's)
    > > > is to clear Clipboard - not so polite to the user; another one is to
    > > > calculate
    > > > CRC32 which means tangible delay while copying big pictures. Is there

    > some
    > > > decent method doing things - to determine that WM_DRAWCLIPBOARD repeats

    > by
    > > > reason of program termination or something?
    > > >
    > > > I'd appreciate copying replies (if any) to my e-mail address.
    > > >
    > > > Thanks in advance,
    > > > Valentin
    > > >
    > > >
    > > >

    > >

    >



  8. #8
    Valentin Bakhov Guest

    Re: Excessive occurences of WM_DRAWCLIPBOARD messages

    Thanks a lot, Karl. Seems CRC32 is the only way to proceed, though, because
    every app has its own way to make mischieve to Clipboard .

    Best regards,
    Valentin

    Karl E. Peterson <karl@mvps.org> wrote in message
    news:3b1533c3$1@news.devx.com...
    > Hi Valentin --
    >
    > Yes, I've repro'd what you're talking about here, too. As I suggested, I

    do think
    > it's something going on behind the scenes, in how these apps are using the

    clipboard
    > internally. You might be able to deduce what's up with some wild

    experimentations,
    > perhaps using the ClipEx.zip sample from my site as a starting point?
    >
    > For example, the acrobat issue you mention causes me to think they're

    calling
    > OpenClipboard/CloseClipboard for each format they put on it, rather than

    just once?
    > That would be something to test. Try putting multiple items on the

    clipboard in
    > different ways, and observe what messages are generated.
    >
    > What you're seeing is just too inconsistent to be something other than

    uniquely tied
    > to the internals of the apps you're using, I'm afraid.
    >
    > Later... Karl
    > --
    > http://www.mvps.org/vb




  9. #9
    Valentin Bakhov Guest

    Re: Excessive occurences of WM_DRAWCLIPBOARD messages

    Thanks a lot, Karl. Seems CRC32 is the only way to proceed, though, because
    every app has its own way to make mischieve to Clipboard .

    Best regards,
    Valentin

    Karl E. Peterson <karl@mvps.org> wrote in message
    news:3b1533c3$1@news.devx.com...
    > Hi Valentin --
    >
    > Yes, I've repro'd what you're talking about here, too. As I suggested, I

    do think
    > it's something going on behind the scenes, in how these apps are using the

    clipboard
    > internally. You might be able to deduce what's up with some wild

    experimentations,
    > perhaps using the ClipEx.zip sample from my site as a starting point?
    >
    > For example, the acrobat issue you mention causes me to think they're

    calling
    > OpenClipboard/CloseClipboard for each format they put on it, rather than

    just once?
    > That would be something to test. Try putting multiple items on the

    clipboard in
    > different ways, and observe what messages are generated.
    >
    > What you're seeing is just too inconsistent to be something other than

    uniquely tied
    > to the internals of the apps you're using, I'm afraid.
    >
    > Later... Karl
    > --
    > http://www.mvps.org/vb




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center