[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                   
---------------------------+------------------------------------------------
Comment (by glynn):

 Replying to [comment:13 marisn]:

 > > > As lib/forms F_open is used only by v.digit and d.what.vect,
 > >
 > > It's used by d.what.vect and NVIZ.
 > >
 > d.what.vect AFAIK doesn't work on Windows due to X dependency. Not a
 issue.
 > NVIZ does '''NOT''' use F_open(). lib/forms are used by more than
 v.digit and d.what.vect modules, but only those two call F_open(). Others
 use plain F_generate, which works just fine.

 v.digit doesn't use lib/form's F_{open,clear,close} functions; it has its
 own functions with those names, which don't spawn a separate process.
 Except, linking against lib/form for F_generate() seems to cause
 lib/form's F_open (etc) to override the local version.

 It would be possible to modify v.digit to use different names (this may
 also need to be done for reset_values(), set_value() and submit() in
 form.c), but I'm still concerned about the potential side-effects of
 linking against lib/form. Personally, I consider cloning F_generate() to
 be the lesser evil.

 If d.what.vect is the only module which uses lib/form's F_open(), I'd
 consider removing that code from lib/form and putting it in d.what.vect
 instead. That would simplify lib/form and eliminate the Windows issues.

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