EMF::METAFILEDEVICECONTEXT(3)

πŸ“¦
version 1.0.13 Β· 5 versions
, in debian trixie, ubuntu questing

πŸ’– EMF::METAFILEDEVICECONTEXT πŸ’–

okay bestie, welcome to the libemf man page for EMF::METAFILEDEVICECONTEXT β€” yes it's a mouthful, yes it's iconic, and yes it is literally the Graphics Device Context. This is the group chat recap you needed. πŸ’…


✨ NAME ✨

EMF::METAFILEDEVICECONTEXT β€” Graphics Device Context. that's it, that's the vibe. πŸŽ€


πŸ¦‹ SYNOPSIS πŸ¦‹

#include <libemf.h>

Inherits EMF::OBJECT. (yes she's got lineage, main character energy runs in the family πŸ‘‘)

🌸 Public Member Functions 🌸

  • METAFILEDEVICECONTEXT (FILE *fp_, const RECT *size, LPCWSTR description_w) β€” the constructor, we'll get into her whole deal below
  • virtual ~METAFILEDEVICECONTEXT () β€” the destructor, she cleans up after the party 🧹
  • OBJECTTYPE getType (void) const β€” tells you what type of object this is
  • DWORD nextHandle (void) β€” hands you the next free handle
  • void clearHandle (DWORD handle) β€” marks a handle as no longer in use
  • void appendRecord (METARECORD *record) β€” shove a record into the metafile
  • void appendHandle (METARECORD *record) β€” shove a record in and bump the handle count
  • void deleteMetafile (void) β€” nukes all the records
  • void mergePoint (const LONG &x, const LONG &y) β€” the long-and-lat version of mergePoint
  • void mergePoint (const POINT &p) β€” the POINT version, this one actually does the work

🌈 Public Member Functions inherited from EMF::OBJECT 🌈

  • virtual ~OBJECT () β€” OBJECTs have a virtual destructor.
  • OBJECT (void) β€” default constructor, no thoughts, head empty πŸ’­

πŸ“ Data Fields πŸ“

  • ::FILE * fp
  • DATASTREAM ds
  • ENHMETAHEADER * header
  • std::vector< EMF::METARECORD * > records
  • SIZEL resolution β€” The resolution in DPI of the reference DC.
  • SIZEL viewport_ext β€” The extent of the viewport.
  • POINT viewport_org β€” The origin of the viewport.
  • SIZEL window_ext β€” The extent of the window.
  • POINT window_org β€” The origin of the window.
  • bool update_frame β€” Update the frame automatically?
  • POINT min_device_point β€” The lft/top-most painted point in device units.
  • POINT max_device_point β€” The rgt/btm-most painted point in device units.
  • POINT point β€” The current point.
  • PEN * pen β€” The current pen.
  • BRUSH * brush β€” The current brush.
  • FONT * font β€” The current font.
  • PALETTE * palette β€” The current palette.
  • UINT text_alignment β€” The current text alignment.
  • COLORREF text_color β€” The current text foreground color.
  • COLORREF bk_color β€” The current background color.
  • INT bk_mode β€” The current background mode.
  • INT polyfill_mode β€” The current polygon fill mode.
  • INT map_mode β€” The current mapping mode.
  • FLOAT miter_limit β€” The current miter length limit.
  • std::vector< bool > handles
  • std::map< HGDIOBJ, HGDIOBJ > emf_handles

πŸ’œ Data Fields inherited from EMF::OBJECT πŸ’œ

  • HGDIOBJ handle

πŸ’… Detailed Description πŸ’…

Graphics Device Context.

okay so, real talk: almost all GDI graphics calls need a device context β€” the only exceptions being the ones that literally create graphics objects, like pens and fonts. periodt.

This particular one is a specific context which renders to a metafile. And bestie, listen β€” there is a one-to-one correspondence between the device context and the metafile. they're matched. soulmates. you don't separate them. πŸ’ž


✨ Constructor & Destructor Documentation ✨

πŸŽ€ EMF::METAFILEDEVICECONTEXT::METAFILEDEVICECONTEXT (FILE * fp_, const RECT * size, LPCWSTR description_w) [inline] πŸŽ€

so the tea here is that most graphics programs seem to want to handle the opening and closing of files themselves, so this is an extension to the w32 interface. thoughtful of her honestly. 🫢

Parameters

  • fp_ β€” stdio pointer to an open file. May be null.
  • size β€” the rectangle describing the position and size of the metafile on the 'page'. May be null.
  • description_w β€” a UNICODE string describing the metafile. The format must be 'some text\0some more text\0\0'. May be null.
⚠️ bestie, note that format string literally β€” 'some text\0some more text\0\0' β€” those null terminators are not a suggestion, they're the whole assignment. πŸ’€

🧚 virtual EMF::METAFILEDEVICECONTEXT::~METAFILEDEVICECONTEXT () [inline], [virtual] 🧚

Destructor frees all the graphics objects which may have been allocated. And now, it also frees any metarecords which it might hold, too. she's thorough, she doesn't leave a mess. 🌸

References deleteMetafile(), and records.


🌈 Member Function Documentation 🌈

πŸ“ void EMF::METAFILEDEVICECONTEXT::appendHandle (METARECORD * record) [inline] πŸ“

Add this record to the metafile.

Parameters

  • record β€” this record is an object so it increments the handle count as well. two birds, one iconic move. ✨

References header, records, and EMF::METARECORD::size().

πŸ“ void EMF::METAFILEDEVICECONTEXT::appendRecord (METARECORD * record) [inline] πŸ“

Add this record to the metafile.

Parameters

  • record β€” standard graphics record. no handle-count drama here, just the record itself.

References header, records, and EMF::METARECORD::size().

πŸ“ void EMF::METAFILEDEVICECONTEXT::clearHandle (DWORD handle) [inline] πŸ“

Clear the usage of this handle. freeing her up for reuse, we love recycling 🫢

References EMF::OBJECT::handle, and handles.

πŸ“ void EMF::METAFILEDEVICECONTEXT::deleteMetafile (void) [inline] πŸ“

Delete all the records from the metafile. and ngl, this would seem to include deleting the header record as well. πŸ’€ gone. all of it.

References records.

Referenced by ~METAFILEDEVICECONTEXT().

πŸ“ OBJECTTYPE EMF::METAFILEDEVICECONTEXT::getType (void) const [inline], [virtual] πŸ“

Return the type of this object (could probably do better with RTTI()). we're keeping it real, we're keeping it honest. πŸ™ˆ

Implements EMF::OBJECT.

πŸ“ void EMF::METAFILEDEVICECONTEXT::mergePoint (const LONG & x, const LONG & y) [inline] πŸ“

Somewhat superfluous, except checker doesn't understand the initialization of automatic structures in the declaration. she's just here so the checker stops being weird about it. 😭

References mergePoint().

Referenced by mergePoint().

πŸ“ void EMF::METAFILEDEVICECONTEXT::mergePoint (const POINT & p) [inline] πŸ“

Take the given point and determine if it enlarges the 'painted' area of the device. the real one. the one that does the math. πŸ’…

References header, max_device_point, min_device_point, update_frame, viewport_ext, viewport_org, window_ext, and window_org.

πŸ“ DWORD EMF::METAFILEDEVICECONTEXT::nextHandle (void) [inline] πŸ“

Scan the bit vector of used handles and return the index of the first free bit as this objects metafile handle. first free spot wins, no queue-jumping. πŸ‘‘

References handles, header, and EMF::ENHMETAHEADER::size().


πŸ‘‘ Field Documentation πŸ‘‘

πŸ’œ DATASTREAM EMF::METAFILEDEVICECONTEXT::ds πŸ’œ

All i/o to the metafile is wrapped by this class so that byte swapping on big-endian machines is transparent. she's bilingual, she just doesn't make it your problem. 🌍

πŸ’œ std::map< HGDIOBJ, HGDIOBJ > EMF::METAFILEDEVICECONTEXT::emf_handles πŸ’œ

This map holds the current mapping between EMF handles and global object handles as a metafile is played back (with PlayEnhMetaFile). it's the contact list, fr fr. πŸ“‡

Referenced by EMF::EMRSELECTOBJECT::execute(), EMF::EMRDELETEOBJECT::execute(), EMF::EMRCREATEPEN::execute(), EMF::EMREXTCREATEPEN::execute(), EMF::EMRCREATEBRUSHINDIRECT::execute(), and EMF::EMREXTCREATEFONTINDIRECTW::execute().

πŸ’œ ::FILE* EMF::METAFILEDEVICECONTEXT::fp πŸ’œ

If it is a file-based metafile, then this pointer is not null. that's the whole test. if it's pointing, it's file-based. 🎯

πŸ’œ std::vector< bool > EMF::METAFILEDEVICECONTEXT::handles πŸ’œ

For compatibility, it appears that metafile handles are reused as objects are deleted. Attempt to emulate that behavior with a bit vector of used metafile handles. cosplay, but make it faithful. 🎭

Referenced by clearHandle(), and nextHandle().

πŸ’œ ENHMETAHEADER* EMF::METAFILEDEVICECONTEXT::header πŸ’œ

Serves double duty as the physical device description. two jobs, one pointer, she's booked and busy. πŸ’…

Referenced by appendHandle(), appendRecord(), mergePoint(), and nextHandle().

πŸ’œ std::vector< EMF::METARECORD* > EMF::METAFILEDEVICECONTEXT::records πŸ’œ

All of the metafile records are stored in memory. every single one. in memory. 🧠✨

Referenced by appendHandle(), appendRecord(), deleteMetafile(), and ~METAFILEDEVICECONTEXT().


πŸŽ€ Author πŸŽ€

Generated automatically by Doxygen for libemf from the source code. not a human, just a very diligent little robot. be nice to her. πŸ€–πŸ’–


and that's the whole page bestie!! πŸ¦‹βœ¨ you made it to the end, that's Version 1.0.9, dated Thu Jun 6 2024 23:01:0 β€” go forth and render to metafiles, you absolute icon. πŸ’…πŸ‘‘πŸ’–

πŸ“¦ where this page comes from