Labels don't display (if the .DBF file doesn't have write permission)

Nov 30, 2011 at 6:07 PM
Edited Dec 1, 2011 at 3:28 PM

Greetings,

I'm currently working a project that requires installing our application within the Windows 7 Program Files folder.  The application needs to generate labels. The problem is that if the .DBF file, the one paired with the shapefile, is only granted read permission, then the labels will not be drawn.  If I give the .DBF file special write permissions as well, then the labels generate just fine. 

Shapefile sfObject= new Shapefile();
sfObject.Open(@"C:\Program Files (x86)\Our Company\Shapefiles\shapefile.shp", true);
sfObject.GenerateLabels(1, tkLabelPositioning.lpCentroid, true);
int shapeFileIndex = AxMap1.AddLayer(sfWorld, true);
The above code is not copied directly from our code.  It's C#.
Are there any other calls that could allow the .DBF to open with only read only permissions? Is there a step in the code that I am missing to allow this?
Thanks,
Stephen 

[Edit: Added information]
Looking through the MapWinGIS C++ source code, in Shapefile.cpp, I've identified where the three files (.shp, .shx, and .dbf) are opened.
The DBF file is not opened using fopen or _wfopen, but instead uses a different method:

CoCreateInstance(CLSID_Table,NULL,CLSCTX_INPROC_SERVER,IID_ITable,(void**)&dbf);
dbf->put_GlobalCallback(globalCallback);
dbf->Open(A2BSTR(_dbffileName), cBack, &vbretval);

I'm not certain what the "dbf->Open(...)" call is doing in this case (as far as the permissions usage are concerned).

Question: Does the DBF file have to be opened with write permissions?
Is there another way to open the files?  A global setting of some sort?
Any help would be greatly appreciated!
Feb 19, 2013 at 9:04 AM
Hi,

We are noticing the same problem. Did you have any progress on that issue ? Did you manage to solve it ?
Does the open function is the source of the problem ?

We haven't tried to use mapwingis 4.9 to see if the problem is still there, but does this problem has been resolved on that version ?


Thanks
Developer
Feb 21, 2013 at 1:00 PM
This issue should be resolved in the latest 4.8 beta installer. You can find it here - http://tinyurl.com/mwMonthly
Feb 22, 2013 at 8:06 AM
Edited Feb 22, 2013 at 8:17 AM
Hi,

Is this an installer problem ? We have built the latest source revision of mapwingis trunk to try to debug it. The problem still appears but we cannot reproduce it while debugging.

We will try the beta version. Is it a built of the mapwingis trunk ?

Another question : mapwingis 4.9 is in the 4.9 branch right ? Why does the new commits are in trunk ?
What is the 4.8 revision or location ?

Thanks
Feb 22, 2013 at 3:55 PM
Hi again,

The beta installer didn't solve the problem.
We have found the reason of our problem. In the TableClass.cpp line 1742 there is a call to _getcwd, in our case this returns the working directory, which is in program files. Thus on Seven the UAC blocks the writing process if level is set by default.
The _getcwd function doesn't seems to be a good solution for that. It would be better to use a real temp path, and use appdata/local and appdata/localLow for seven.

The _getcwd function is used also in some other places, it can cause problems too (gridtoshp).


Cheers
Feb 28, 2013 at 9:56 AM
Edited Feb 28, 2013 at 9:57 AM
Hi,

What do you think about the getcwd function ? Why is this function used ?
Should the applciation be run in a writable current directory ?

To my mind the current implementation is very bad and should be changed to a real temp file creation.
Coordinator
Mar 4, 2013 at 3:35 PM
As Brad said, this has been fixed.
Can you grab the latest version of the ocx using Update2Svn: http://www.mapwindow.org/phorum/read.php?4,24284

The trunk version here at mapwingis.codeplex is the current version (=v4.8). v4.9 is in the branch and will be move to the trunk when MapWindow v4.8.8 is out.
After that we'll work with v4.9 of the ocx and make a MapWindow v4.9.
I hope this explains the version numbers a bit ;)

Paul
Mar 4, 2013 at 5:14 PM
Hi,

Thanks for the versionning information, I understand, so version 4.8 is still evolving to a future release 4.8.8.

I just checked the latest commited source code, but the creation of the temporary file still refers to _getcwd function (trunk/COM classes/TableClass.cpp:1742) . Maybe something was commited in the rest of the code lately. But when i tested the commit #71111 I managed to reproduce the problem (I just retested with the last commit 71355 same problem).

When building our program using the binary provided by Update2SVN we are experiencing the same issue.

When you say that it's resolved do you mean that it's resolved in the MapWinGis binary ? Or resolved in MapWindow (maybe mapwindow is changing the working directory )?


The program is a basic program that creates a new shapefile, add fields and fills the attribute for few shapes in it.

My steps to reproduce the problem :
Case 1) running from VS :
-Windows 7, uac enabled set to default.
-Building the program Vc++ 2008 or 2010 project that uses mapwingis ocx.
-Debugging or running in release mode the project, => no problem.

Case 2) Running from program file :
-Windows 7, uac enabled set to default.
-Building the program Vc++ 2008 or 2010 project that uses mapwingis ocx.
-Copiing the exe to a directory in program files and run it from here => Shapefiles are correctly created and modified but, attribute table remains empty.

Case 3) Running from program file, changing current directory
-Windows 7, uac enabled set to default.
-Building the program Vc++ 2008 or 2010 project that uses mapwingis ocx.
-Copiing the exe to a directory in program files, creating a shortcut to this and change the "start from" directory in the shortcut to the current user desktop => shapefiles and attribute tables are correct, a temporary file appears on the desktop also, seems to be a dbf file, it contains the attributes and fields created by the test program.

More details :
  • When UAC is disabled completely there are no problems.
  • when run from Visual Studio the working directory is set to the program's release directory.
Cheers

Pierre
Developer
Mar 5, 2013 at 1:14 PM
Edited Mar 5, 2013 at 1:23 PM
If you saw this reply before I changed it, please disregard.

So let me make sure I understand. You are saying that the location of the built exe within the file system is determining whether or not the labels are drawn?

Are you moving the location of the "shp", "shx", and "dbf" files as well?

Can you try using the "Run as Administrator" option for the exe when it is located in the Program Files directory? This probably won't tell us much, but it will be another data point.

Thanks.
Brad
Mar 5, 2013 at 1:57 PM
Hi Brad,

Yes the location from which is run the application changes the behaviour, by debuging MapWinGis we have found that a temporary file is created in the working directory, i.e. the directory from were is run the application, if it's not changed during execution.

Actually the problem is not really that labels doesn't appears, this is not a display problem, but truly an attribute table creation problem.

"Are you moving the location of the "shp", "shx", and "dbf" files as well?" :
Wherever we store the output shapefile the problem appears (because a temp file is create anyway for storing a kind of temporary attribute table).

Run as administrator solves the problem for sure because it bypasses the UAC of windows 7, thus the program has all write permission to any directory. But running the application as admin should not be the solution as there is no need to run it as admin.

Actually we are just pointing out a wrong use of the _getcwd function that causes the attribute table not to be written in particular cases, but somehow quite common configurations. We have a fixed for that : replacing the call to _getcwd function by a getTempPath function that points to a directory always writeable for the user (appdata/local or locallow). Applying this fix to a recompiled ocx leads to a correct creation of the attribute table.

So the main question is : does a mapwingis developper agrees with this solution ? Or does the getcwd function is used on purpose in this case ?


Thanks
Pierre
Developer
Mar 5, 2013 at 2:15 PM
I understand now. Thanks for explaining with so much detail. You are correct. We should not be trying to create the temporary file in the current working directory.

I think we could use a combination of GetTempPath and GetTempFileName to generate the full temp file path. This should guarantee that the path is always accessible by the current user.

Did this ever get filed in Mantis? If not, would you mind filing it?
Mar 5, 2013 at 2:24 PM
I filled it in the codeplex issue tracker recently (http://mapwingis.codeplex.com/workitem/24005) i don't know if it's the place you meant.

The functions you mention should do the trick.
Developer
Mar 5, 2013 at 2:25 PM
I understand now. Thanks for explaining with so much detail. You are correct. We should not be trying to create the temporary file in the current working directory.

I think we could use a combination of GetTempPath and GetTempFileName to generate the full temp file path. This should guarantee that the path is always accessible by the current user.

Did this ever get filed in Mantis? If not, would you mind filing it?
Developer
Mar 5, 2013 at 2:25 PM
I understand now. Thanks for explaining with so much detail. You are correct. We should not be trying to create the temporary file in the current working directory.

I think we could use a combination of GetTempPath and GetTempFileName to generate the full temp file path. This should guarantee that the path is always accessible by the current user.

Did this ever get filed in Mantis? If not, would you mind filing it?
Mar 5, 2013 at 3:15 PM
By the way, _getcwd function is used in some other places ( grid management if i remember well). Maybe it it worth replacing it everywhere in the code ...
Developer
Mar 5, 2013 at 4:20 PM
Yep, you are correct again. There are a few places where _getcwd is correct, but any place that we are trying to get a temporary file should not use _getcwd. I will try to have a fix for this soon. Thanks.

Brad
Coordinator
Mar 7, 2013 at 8:23 PM
Brad has made a fix and I have just committed new binaries.
Read this post how to get the latest binaries:
http://www.mapwindow.org/phorum/read.php?4,24284,24383#msg-24383

Let us know if this is fixing your problem.

Thanks,
Paul
Mar 8, 2013 at 1:31 PM
Hi,

Great, we have checked with the ocx and the problem doesn't appears anymore.

Thanks for your help !

Pierre
Coordinator
Mar 15, 2013 at 2:36 PM
Thank you for testing and I'm glad the fix worked.