Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PCopy vs. _CopyImage
#3
PCopy is a great tool for making a quick copy of a screen and then restoring it afterwards.  I highly recommend it for its simplicity for most folks.  Only problem it has, that can be a PITA is.... How does one ever free that copy once you're done with it?

PCOPY 0, 1

So the above made a copy of the active display (0) and saved it as copy (1).... Now we can overwrite that copy (1) just by issuing the command again, but... how the heck do we free it when we're completely done with it??

Code: (Select All)
PCopy 0, image
_FreeImage image

The above will error out on us.  We can't just _Freeimage that PCOPY and clear it from memory.   It tends to hang around and last as long as they existing display does -- and that might not be what you want, if you're shooting to preserve minimal resources in your program.



_CopyImage lets us make a copy of the screen just like PCOPY does, but it doesn't allow for safe overwriting of the screen like PCOPY.

FOR i = 1 TO 10
   PCOPY 0, 1
NEXT

The above simply makes a copy of the display in copy(1), and then overwrites it automatically.   You can't ever really get rid of Page(1) and free it from memory, but you can safely overwrite it.

FOR i = 1 TO 10
    image = _COPYIMAGE(0)
NEXT

The above will now make 10 copies of screen 0 and assign them screen handle values.  Since those handles are being stored in the same variable, the reference variable is being overwritten but those copies of the image are still floating around in memory.  _COPYIMAGE won't use the same page like PCOPY will, so it doesn't overwrite the same block of memory repeatedly like PCOPY would.

Note, however, that with  _COPYIMAGE you have the ability to _FREEIMAGE those handles completely.  You just have to do it manually as the program won't do any automagic clean up for you.



Note that you're getting the both of both worlds with the way you're doing things.

image2& = _newimage(x , y, z)   <-- you set a static screen which is the same as your original screen
PCOPY image, image2&   <-- you use PCOPY to store the first screen on that static screen, without creating a whole new handle
_FREEIMAGE image2A  <-- you then free that handle when you're done with it.

This works for you because everything lines up and matches properly.  If image2 was a different width, height, bit depth than your other screen, it couldn't just autocopy over like this and would toss an error for you.

Personally, I'm of the habit of just making certain I always use _FREEIMAGE religiously in my code, but the way you're doing things here looks to me like it should work fine and without issues.   Just be careful of the pitfalls no matter which style you use, and code in the manner that suits you the best.  The commands aren't identical, and each has its own drawbacks and issues to consider and be careful of.  Just choose the method you like best and be careful of any memory leaks or impossible to free images.  Wink
Reply


Messages In This Thread
PCopy vs. _CopyImage - by NakedApe - 07-27-2025, 02:02 AM
RE: PCopy vs. _CopyImage - by DSMan195276 - 07-27-2025, 02:15 AM
RE: PCopy vs. _CopyImage - by SMcNeill - 07-27-2025, 02:36 AM
RE: PCopy vs. _CopyImage - by NakedApe - 07-27-2025, 03:50 AM

Possibly Related Threads…
Thread Author Replies Views Last Post
  PCOPY use with hardware and software images TerryRitchie 7 1,622 08-13-2024, 09:19 PM
Last Post: Pete

Forum Jump:


Users browsing this thread: 1 Guest(s)