[GRASS-dev] Re: [GRASS GIS] #843: v.digit broken on new WinGrass release

[GRASS GIS]

#843: v.digit broken on new WinGrass release
---------------------------+------------------------------------------------
  Reporter:  cnielsen      |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect        |      Status:  new                      
  Priority:  critical      |   Milestone:  6.4.0                    
 Component:  Vector        |     Version:  unspecified              
Resolution:                |    Keywords:  wingrass,v.digit         
  Platform:  MSWindows XP  |         Cpu:  x86-64                   
---------------------------+------------------------------------------------
Changes (by hamish):

  * priority:  normal => critical

Comment:

 I can reproduce this now from both the wx and tcltk GUIs.

  digitize [new] -> settings -> table tab -> create table -> ok
 (interestingly the dbf.exe empty dosbox locked up when I tried to run it
 from gis.m)

 then draw a boundary with "No category" set, move vertex to snap it shut,
 then try to add a centroid with cats set to "Next not used".
 Boom, G_fatal_error( "F_open_*() doesn't do ms windows").

 In my earlier test I didn't try to do anything with an attribute table.

 I expect that the tcl version of d.what.vect will have the same problem as
 it also uses the form library.

 Replying to [comment:4 cmbarton]:
 > Could it be the fully qualified map name (map at mapset)?

 it's this in lib/form/open.c:

 {{{
 /* Open new form
  *
  *  returns: 0 success
  */
 #ifdef __MINGW32__
 int F_open(char *title, char *html)
 {
     G_fatal_error("F_open is not supported on Windows");
     return 1;
 }
 #else
 int F_open(char *title, char *html)
 {
     /* parent */
     int c;

     /* common */
     static int pid;

 #ifndef HAVE_SOCKET
     static int p1[2], p2[2];
 #endif /*HAVE_SOCKET */
     int length;

     /* child */

     G_debug(2, "F_open(): title = %s", title);

     if (first) {
 #ifdef HAVE_SOCKET
 ...
 }}}


 the question is, is that fatal error really necessary if all the UNIX
 socket code is protected?


 bumping up the priority level of this bug as currently there is no vector
 digitizing functionality available on MS Win, which is not a good
 situation.

 Workarounds: use the qgis digitizer or cygwin build.



 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/843#comment:5>
GRASS GIS <http://grass.osgeo.org>