Hi Jim,
I've looked at the wingdi I was earlier working with, and the
commoncontrols initialization was commented out
for the #ifdef _WIN64 case. I'm unsure whether I tested with w64, I think
so. But in the current attempt, I
was definitely confined to a 32-bit system - it may be the case that this
function is unavailable.
in module wingdi_modul_initialize( void ) :
> #ifdef _WIN64
>
> // Initialize common controls
>
> init_controls.dwSize = sizeof(INITCOMMONCONTROLSEX);
>
> init_controls.dwICC = ICC_BAR_CLASSES;
>
> if( ! InitCommonControlsEx( &init_controls ) )
>
> {
>
> plwarn( "wingdi: Failed to initialize common Window controls\n" );
>
> }
>
> #endif
>
>
> Also to mention, it would be a great convenience if HWND - plot and HDC
- hdc were again placed at the top of
the wingdi_Dev struct. As such, the replacement of wingcc with wingdi is
already accommodated in GDL as a compile-time macro.
> // Device-specific info per stream
>
> struct wingdi_Dev
>
> {
>
> //
>
> // WIN32 API variables
>
> //
>
> HWND plot; // Handle for the plot area
>
> HDC hdc; // Plot window device context
>
> HPEN pen; // Current pen used for drawing
>
> ...
Thanks,
Greg
On Sun, Dec 31, 2017 at 5:14 AM, Jim Dishaw <j...@dishaw.org> wrote:
> I think that is a Windows vs Windows 8. I will look at that today and
> patch.
>
> On Dec 31, 2017, at 1:10 AM, Greg Jung <gvj...@gmail.com> wrote:
>
> Hi guys,
> Because my main PC (win 7) is busted I am working with a backup system
> which is windows 8.1 pro 32-bits
> and I was interested in deploying the new wingdi for GDL on windows.
> Although no errors were anticipated from the
> cmake processing (required setting PLD_wingdi=ON) the build came up
> short finding a library:
>
>> Scanning dependencies of target wingdi
>>
>> [ 67%] Building C object drivers/CMakeFiles/wingdi.dir/wingdi.c.obj
>>
>> [ 67%] Linking C shared module ../dll/wingdi.dll
>>
>> CMakeFiles/wingdi.dir/objects.a(wingdi.c.obj):wingdi.c:(.text+0x1bb7):
>>> undefined reference to `_imp__InitCommonControlsEx@4'
>>
>> collect2.exe: error: ld returned 1 exit status
>>
>> make[2]: *** [drivers/CMakeFiles/wingdi.dir/build.make:104:
>>> dll/wingdi.dll] Error 1
>>
>> make[1]: *** [CMakeFiles/Makefile2:1263: drivers/CMakeFiles/wingdi.dir/all]
>>> Error 2
>>
>> make: *** [Makefile:152: all] Error 2
>>
>>
> I also found, although it isn't important for me downstream, that my QHULL
> installation was not found correctly. I checked where they were to be
> found, here is a partial listing of that:
>
>> $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files
>>
>> %FILES%
>>
>> mingw32/
>>
>> mingw32/bin/
>>
>> mingw32/bin/qconvex.exe
>>
>> mingw32/bin/qdelaunay.exe
>>
>> mingw32/bin/qhalf.exe
>>
>> mingw32/bin/qhull.exe
>>
>> mingw32/bin/qvoronoi.exe
>>
>> mingw32/bin/rbox.exe
>>
>> mingw32/include/
>>
>> mingw32/include/qhull/
>>
>> mingw32/include/qhull/geom.h
>>
>> mingw32/include/qhull/libqhull.h
>>
>>
>>
> On Fri, Oct 6, 2017 at 11:06 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
> wrote:
>
>> On 2017-10-06 11:00+0100 Phil Rosenberg wrote:
>>
>> Given that the libraries in question are in the standard c and C++
>>> libraries. I just tested to see what the impact is of simply
>>> commenting out the checks for these two libraries.
>>>
>>> The result is that wingcc is accepted onto the driver list, appears in
>>> my plplot VC++ project, everything builds correctly and I can run the
>>> examples and select the wingcc device and everything runs fine.
>>>
>>> Given that this is the case is there even a need to check for these
>>> libraries? Or is this test needed for Cygwin or minGW builds?
>>>
>>
>> The present library finding has "just worked" for a long time for a
>> large variety of Windows users on many different Windows platforms so
>> I am somewhat reluctant to change it. On the other hand, I guess it
>> is possible if you don't need it, then nobody needs it, but I am not
>> at all sure about that. So before making any decisions here, I think
>> we need to collect more information. For example, I would like you to
>> try 3.9.4 (see other thread concerning CMake versions) to see if this
>> particular problem persists (and also to determine whether CMake-3.9.4
>> satisfies all PLplot build-system needs for your Windows SDK version.)
>>
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> Astronomical research affiliation with Department of Physics and
>> Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __________________________
>>
>> Linux-powered Science
>> __________________________
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Plplot-devel mailing list
>> Plplot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
