Tutor_14 (C++ VS2022 GDImage64 tutorial)

[Patrice Terrier]

Fourteenth post of a series, translated from the "WinDev and PowerBASIC",
to explain the use of GDImage64 in procedural* programming mode with Visual Studio 2022.

About Tutor_14
It is based on a real application written in 2007 for a french administration (Prefecture du Vaucluse).
It uses markers to spot a specific location on a map or a plan.
It is able to manage several distinct projects, each one using a main background image, that is the surface used to display the markers and the annotations, the coordinates and properties of the objects are saved inside the application's "Map" subfolder. The file name used to save a project, is build on the name of the background image, followed with the extension ".gns".

Zoom Control
The ZI_SetProperty(gP.hCtrl, ZI_ZoomWindow, TRUE); enabled it.
It means that everything put inside of the graphic control could be resized on the fly.

Vertical selector
This is the same concept as the vertical sprite selector used in Tutor_13, except that this one is a tool window that can be moved around by dragging its caption.

Drag & drop
Uses the CreateDropImage procedure to create a WS_EX_LAYERED window to drag the selected sprite to its destination.

RTF help file
Please make sure to read the provided HELP_us.rtf by cliking the user icon shown aside the close button (bottom right side).

User interface
1. Contact sheet:
Located above the main working area, it allows the selection of a specific project.
The active project is shown in opaque mode, while the others are using half transparency.
2. Working area:
Located below the contact sheet and above the command pannel, it takes most of the main window area. The aspect of the working area relies on the zooming factor being used, and the view port section can be adjusted with the scrollbars. It is also possible to scroll the image using the left mouse button to drag directly the background.
3. Markers:
They are shown inside of the floating tool window located on the right side of the working area.
To add new markers on the working area, just use drag and drop from this window.
4. Command pannel:
It is at the bottom of the main window, under the working area. It is used to display the mouse coordinates and all the command buttons, as well as the "Close" button (on the right side). You can use the command panel, as you would do for a standard window caption, to move the whole window to another location (using drag and drop).
5. Moving and zooming:
This small floating toold window is located on the top left corner, it is used to display a thumbnail of the whole background image, altogether with a rectangular shape, using a red perimeter to delimit the part of the image currently shown in the working area. The size of the rectangle, is based on the current zoom level, that could be adjusted from the horizontal slider below the thumbnail. You can drag the inside of the rectangle, to adjust the viewport, just like what you would do with the scrollbars aside the working area.

GDImage 7.15
Is an experimental version converted to VS2022, and designed specifically to run all the Tutor applications.


   
* procedural programming mode, is based on direct use of the FLAT API (Windows SDK) that is the core meat of the OS.

[Shao Voon Wong]

Hi Patrice,

I cannot build in debug x64 x86 build and release x86 build of your Tutor 14. There are some errors and many errors due to the invalid WCHAR* conversion. If I try out to write some GDImage code, I am not going to start from scratch; I am going to take your existing Tutor 14 code and remove the code which I do not need to write a zooming photo viewer application. I must be able to debug using the debug build when something goes wrong. Right now, I am unable to build a debug build.

In 1990s, using Turbo C. I was able to write something like

Code: [Select]

char* text = "Good Holidays";
Starting from the early 2000s, I was not allowed to do this. A const keyword must be used.

Code: [Select]

const char* text = "Good Holidays";
For example, given the MyFunction below

Code: [Select]

void MyFunction()
{
    char* text = "Good Holidays";
    // code that modifies the content which text is pointing to.
}
If MyFunction modifies "Good Holidays" which is a static memory area, then the next time, MyFunction is called again, the text won't be "Good Holidays". This is why const must be used for string literals. I never verify if this is true because it is an industry practice that every C/C++ developer and I has to follow.

Assigning char* to const char* is allowed.

Code: [Select]

char* text = ???
const char* text2 = text; // allowed
but the opposite is not allowed by the compiler.

Code: [Select]

const char* text = ???
char* text2 = text; // error: not allowed.
Can you modify all the in parameters of WCHAR* to const WCHAR* in GDImage? This is to cut down the compile errors I have to fix when compiling in debug build. The side effort of this modification is you cannot modify const WCHAR* argument inside your function.

What do you think?

[Patrice Terrier]

Sorry I am unsure to understand your concern.
Do you want to build a 32-bit version of Tutor_14 in debug mode?
But what about the GDImage DLL that is 64-bit...

The first thing would be to create a 32-bit version of GDImage working only in ANSI rather than UNICODE.
This is exactly what the old PowerBASIC version does.
Or do you want to have a 32-bit UNICODE version ?

Or you just want to have a 64-bit version of Tutor_14 working in debug mode ?

[Patrice Terrier]

Currently in GDImage the WCHAR constants are defined like this

Code: [Select]

static WCHAR*   $NULL               = L"";
static WCHAR*   $SPACE              = L" ";
static WCHAR*   $CHARNULL           = L"\0";
static WCHAR*   $COMMA              = L",";
static WCHAR*   $ANTI               = L"\\";
static WCHAR*   $DOT                = L".";
static WCHAR*   $SAVE_EXT           = L"PNG,JPG,BMP,TIF,GIF,EMF,WMF";
static WCHAR*   $FILTER             = L"*.PNG (Portable Network Graphic)|*.PNG|*.JPG (JPEG File Interchange)|*.JPG;*.JPEG|*.BMP (Windows Bitmap)|*.BMP|*.TIF (Tagged Image File)|*.TIF;*.TIFF|";
static WCHAR*   $JPG_PNG            = L"JPG,PNG";
static WCHAR*   $ZLIM               = L"|";
static WCHAR*   $LF                 = L"\n";
static WCHAR*   $RegistryKey        = L"SOFTWARE\\GDImage";
static WCHAR*   $RegistryPath       = L"LoadDefaultPathName";

const int SCROLLBAR_NONE     = 0;
const int SCROLLBAR_VERT     = 1;
const int SCROLLBAR_HORZ     = 2;
const int SCROLLBAR_BOTH     = 3;

const int CHECK_FOR_MULTISAMPLE     = TRUE;
const int WGL_SAMPLE_BUFFERS_ARB    = 0x2041;
const int WGL_SAMPLES_ARB           = 0x2042;
const int WGL_DRAW_TO_WINDOW_ARB    = 0x2001;
const int WGL_SUPPORT_OPENGL_ARB    = 0x2010;
const int WGL_ACCELERATION_ARB      = 0x2003;
const int WGL_FULL_ACCELERATION_ARB = 0x2027;
const int WGL_COLOR_BITS_ARB        = 0x2014;
const int WGL_ALPHA_BITS_ARB        = 0x201B;
const int WGL_DEPTH_BITS_ARB        = 0x2022;
const int WGL_STENCIL_BITS_ARB      = 0x2023;
const int WGL_DOUBLE_BUFFER_ARB     = 0x2011;

[Shao Voon Wong]

Sorry I am unsure to understand your concern.
Do you want to build a 32-bit version of Tutor_14 in debug mode?
But what about the GDImage DLL that is 64-bit...

The first thing would be to create a 32-bit version of GDImage working only in ANSI rather than UNICODE.
This is exactly what the old PowerBASIC version does.
Or do you want to have a 32-bit UNICODE version ?

Or you just want to have a 64-bit version of Tutor_14 working in debug mode ?

In that case, I would want 64-bit version of Tutor_14 working in debug mode since I only have 64-bit GDImage. Please show me the relevant settings to make it compilable in 64-bit debug so that I'll know how to do it when I start a new GDImage project.

And can you kindly remove the hidden .vs folder from the source code since that .vs contains regenerated info whenever the solution is opened? And that .vs only contains info relevant to your dev machine which is not useful to me.

Thanks in advance.

[Patrice Terrier]

Here is the Debug version, without the .vs hidden folder.

About the correct Debug settings, open the "Project" --> "Properties" to figure what to do.
The important parts are in these sections
> C/C++
> Linker
 Starting from now,, I shall try to add a Debug version in new tutors.

However keep in mind that the settings for Debug and Release are very different.

Have a look at these settings to produce standalone EXE without using the CRT.
http://www.objreader.com/index.php?topic=335.msg6044#msg6044

[Shao Voon Wong]

Thanks Patrice,

Can you change the IN parameters of WCHAR* type to const WCHAR* type? Windows API uses LPCWSTR which is the same as const WCHAR*

For example, change from

Code: [Select]

C_IMPORT WCHAR*    ZI_SetSaveExtension (IN WCHAR* sExtension, IN long RW);
to

Code: [Select]

C_IMPORT WCHAR*    ZI_SetSaveExtension (IN const WCHAR* sExtension, IN long RW);
You also have to change in the original source code of GDImage and build a new version of GDImage64.dll.

Thanks.

[Shao Voon Wong]

Thanks for removing the .vs folder because I had problems opening the Tutor solution as your .vs point to path of project files on your machine which are different from mine. I always have to delete .vs folder before opening the solution to avoid the opening problem. .vs is to store the intellisense information which can be regenerated.

[Patrice Terrier]

Can you change the IN parameters of WCHAR* type to const WCHAR* type? Windows API uses LPCWSTR which is the same as const WCHAR*

I did try to use const WCHAR*, but that is causing too much havoc into the GDImage64.dll.
Especially when a IN parameter is changed inside of the code for internal uses.

In my code IN means, this parameter is not returned to the calling code, however it could be altered for internal purpose.
In other world, IN doesn't mean it is a const parameter.

The "IN" and "OUT" macros are doing nothing, they are just used for informational purpose.