Calling dll function but file cannot be written when application is open - visual-c++

I have a function in a dll that involves reading and writing a file.
I am calling the dll function in a test application but the file could not be written when the application is still open. I always need to close the test application first before the file could be successfully written.
What do I have to do to fix this?
I am calling the function repeatedly in a loop. When there are multiple items needed to to processed using that function, the application crashes. It works fine when only one item is processed. What can I do?
Note: my dll is actually an .exe that I converted to dll.

My guess would be the file is already open. Is your code doing a file open and then leaving the file open?
Check the code to make sure there is a matching file close for every file open.

Open the file with the right sharing permissions? What API are you using to open the file?

I would recommend using a different file name when you call the function from your test code. If possible, modify the dll to accept a filename.
If not, make sure you open the file in shared mode.

Related

Is there a way to see how my file was edited - node.JS

I have a file and I am reading it through chokidar. I am also writing to the same file in some another function using fs.writeFileSync.
I want to emit the watcher.on('change') function only when the file is changed manually (i.e. not through WriteFileSync). Is there a way of determining that ?
No, there isn't, not to my knowledge.
You can only know the file was changed, not what process/... changed it.

How to share a variable between 2 pyRevit scripts?

I am using the latest version of pyRevit, v45.
I'm writing some info in temporary files with
myTempFile = script.get_instance_data_file("id")
This creates a file named pyRevit_2018_xxxx_id.tmp in which I store useful info. If I'm not mistaken, the "xxxx" part is changing every time I reload Revit. Now, I need to get access to this information from another pyRevit script.
How can I retrieve the name of the temp file I need to read? In other words, how do I access "myTempFile" from within the second script, which has no idea of the name of "myTempFile"?
I guess I can share somehow that variable between my script, but what's the proper way to do this? I know this must be a very basic programming question, but I'm indeed not a programmer ;)
Thanks a lot,
Arnaud.
Ok, I realise now that my variables in the 1st script cease to exist after its execution.
So for now I wrote the file name in another file, of which I know the name.. That works.
But if there's a cleaner way to do this, I'd be glad to learn ;)
Arnaud
pyrevit.script module provides 4 different methods for creating temporary files based on their use case:
get_instance_data_file:
for data files marked with Revit instance pid. This means that scripts running on another instance will not see this temp file.
http://pyrevit.readthedocs.io/en/latest/pyrevit/script.html#pyrevit.script.get_instance_data_file
get_universal_data_file:
for temp files accessible to all Revit instances and versions
http://pyrevit.readthedocs.io/en/latest/pyrevit/script.html#pyrevit.script.get_universal_data_file
get_data_file:
Base method to get a standard temp file for current revit version
http://pyrevit.readthedocs.io/en/latest/pyrevit/script.html#pyrevit.script.get_data_file
get_document_data_file:
temp file marked with active document (so scripts working on another document will not see this)
http://pyrevit.readthedocs.io/en/latest/pyrevit/script.html#pyrevit.script.get_document_data_file
Each method uses a pattern to create the temp file name. So as long as the call to the method is the same of different scripts, the method generates the same file name.
Example:
Script 1:
from pyrevit import script
tfile = script.get_data_file('mydata')
Script 2:
from pyrevit import script
tempfile = script.get_data_file('mydata')
In this example tempfile = tfile since the file id is the same.
There is documentation on each so make sure you take a look at those and pick the flavor that serves your purpose.

Understanding how libzip works

I have started working with the libzip library today. But I do not understand the principle how libzip works.
My focus is on zipping a directory with all the files and dirs within
into a zip-file.
Therefore, I started with zip_open(), then I read the directory
contents and add all the dirs with zip_dir_add() to the archive.
After that, I closed the zip-file with zip_close(). Everything was
fine. The next step should be to add all the files to the archive with
zip_file_add(). But it doesn't work. The last step closing the file
fails.
OK, I forgot to create a zip_source to get this done. I added a
statement a line before to get this source (zip_source_file()). But
still it doesn't work.
What is wrong in my thinking? Do I have to fopen() and fclose() the file on the filesystem also?
And what is the difference between zip_source_file() and zip_source_filep()?
Do I have to fopen() and fclose() the file on the filesystem also?
No, you can just use zip_source_file().
From your comments I think you have the right general idea, but there is probably some detail that is making it fail. Make sure you perform all the error checking the documentation suggests after each libzip call so you can get more information about what is causing it to fail.
You could also compare your code with https://gist.github.com/clalancette/bb5069a09c609e2d33c9858fcc6e170e

Finding the name of excel file from xla

I am using an xla file to run my vba-code in excel. I have many templates, which use this xla file. Is there any way to find which template runs(opens) the xla file from xla.
I have used:
ThisWorkbook.FullName
but it returns the name of the xla file and not the name of the template
I don't think there is a straightforward way for a Function or a Sub to find out who's calling it (because the call/stack tracing is not available programatically to VBA).
You could do your own tracing, by implementing some push and pop operations on a custom-made stack globally accessible in your .xla, for example. When a function is called, it pushes its filename+module+name to the stack, and when it ends it pops that information from the stack.
But then again, it depends on the "benevolence" of the calling function (e.g. the one from the file that references your .xla file) to use your tracing convention. Also, it might make your code more brittle. And also, it could make it worse actually, if you don't handle every exception that might break the execution of your functions/subs.
See also this (last section): http://www.cpearson.com/excel/DebuggingVBA.aspx

CreateFile in separate thread returns INVALID_HANDLE_VALUE in MFC app

I have an MFC App which fires up a separate thread for downloading some files via cURL. At the start it downloads a text file with file sizes and last write times. Then it checks the files on disk and queues it for downloading if it has different values.. The problem is; the CreateFile call in the thread arbitrarily returns INVALID_HANDLE_VALUE. I always do CloseHandle() after a successful CreateFile(). The failing files are just random. Sometimes a file in the root dir, another time a file in a nested directory. The problem is not related to localization or directory/file names since sometimes all checks pass but sometimes don't. GetLastError() return 2 or 3 on occasion which are "File not found" / "Path not found" respectively.
When I put the function checking the file write times and size straight into the OnInitDialog() function, everything works. This smells like a multithreading issue but I double-checked everything from memory allocations to file handles.
The same code works in a console application also in a separate thread.
The platform is Win7 64bit.
Linking statically to the runtime and MFC.
in my case GetCurrentDirectory() returned the system32 path after some time so my code failed because of credentials. I fixed the issue by determining file paths manually (getting the exe path at the start and use it from there on...) . Make sure you are not trying to write to/read from a privileged location on disk. Check your paths.

Resources