I have to deal with importing CSV files. The legacy solution uses MFC and ADO text driver to manage this. I know that you can specify the TextDelimiter-option within the corresponding Schema.ini file.
The problem is, that it is impossible for some input files to specify a character that isn't used within that file!
All our files are CP1252 encoded - we cannot deal with other encodings, so a "☃" (SNOWMAN, U+2603) or stuff like that provide no solution.
If I omit a character, ADO seems to fall back to the default character (doublequotes):
[Import.txt]
ColNameHeader=False
Format=Delimited(;)
TextDelimiter= //← omit character doesn't work!
col1=...
I also cannot define a sequence of characters, which would reduce the risk of mismatches to an acceptable value:
[Import.txt]
ColNameHeader=False
Format=Delimited(;)
TextDelimiter=##+# // produces error when opening the ADO connection!
So my question is: Is it possible to completly disable this feature? I just do not want any automatic text delimiting!
The code is implemented in C++ based upon MFC and ADO - so no ADO.NET solutions will help me.
This should do it:
TextDelimiter=none
Related
I'm generating thumbnails for office files using c++. I open and save the files using automation similar to this: https://support.microsoft.com/en-us/kb/179494. Since there are many files, this takes a lot of time and the program should run through the night.
Everything works fine, except when a file contains an auto start macro, which doesn't even exist.
Sub AutoOpen()
Application.Run ("stupidMacroWhichDoesntExist")
End Sub
In this case, the Loop stops, and an error message appears that the macro couldn't be executed.
Off Course, I have set the macro settings in the trust center to -> disable all macros without notification
The error message still appears
In Excel, I can prevent this with:
objExcelApp.SetEnableEvents(false);
Unfortunately, the word application in c++ doesn't have a SetEnableEvents method. I have googled a lot and found a lot of VB Code to prevent this. Mostly it was something like:
objWord.WordBasic.DisableAutoMacros 1
But I haven't found anything in c++
I'm very thankful for your help.
I believe you're looking for:
WordApplication.AutomationSecurity = msoAutomationSecurityForceDisable
The Trust Center setting doesn't apply to documents being opened using automation. This property and its MsoAutomationSecurity enumeration correspond to that setting in the object model.
FWIW the WordBasic approach should also be possible using C++. I don't know C++ syntax, but with C# I'd need to use PInvoke (GetType().InvokeMember) to communicate directly with the IDispatch (I think that's the right term).
I have solved it. I'm backing up the actual macro (vbaData.xml and vbaProject.bin in the word folder), put a dummy macro into the word file, open it via automation and save it to generate the thumbnail. After that, I put back the backed up macro into the word file.
Since the dummy macro does nothing I am safe that nothing will be executed, whatever is programmed in the original macro.
I have some documentation strings embedded within the source code (C/C++ files) as XML tags and I'd like to know what's the most minimal solution to make vim autoclose the tags (closest matching tag).
I've found closetag.vim but is there away to do this neatly without modifying anything but the .vimrc file?
Vim has no built-in support for that, so the closetag.vim plugin is the proper and easiest solution. (I use it myself, too!) Of course, you can develop your own simple mappings (that search backwards for an open tag, get that, drop the attributes, add the slash, and insert that), but:
that will either be very simplistic and therefore often wrong
or ends up with as much complexity as closetag, becoming a reimplementation of that plugin
If some rather strange restrictions (e.g. a custom primitive sync across systems) only allow you to manipulate the ~/.vimrc itself, you could just append the entire plugin's code to it (though I'd recommend against such an ugly hack).
For educational purposes, I would like to build an IDE for PHP coding.
I made a form app and added OpenFileDialog ..(my c# knowledge was useful, because it was easy ... even though without intelisense!)
Loading a file and reading lines from it is basically the same in every language (even PERL).
But my goal is to write homemade intelisense. I don't need info on the richtextBox and the events it generates, endline, EOF, etc, etc.
The problem I have is, how do I handle the data? line for line?
a struct for each line of text file?
looping all the structs in a linked list? ...
while updating the richtextBox?
searching for opening and closing brackets, variables, etc, etc
I think Microsoft stores a SQL type of database in the app project folders.
But how would you keep track of the variables and simulate them in some sort of form?
I would like to know how to handle this efficiently on dynamic text.
Having never thought this through before, it sounds like an interesting challenge.
Personally, I think you'll have to implement a lexical scanner, tokenizing the entire source file into a source tree, with each token also having information about it mapping the token to a line/character inside of the source file.
From there you can see how far you want to go with it - when someone hovers over a token, it can use the context of the code around it to be more intelligent about the "intellisense" you are providing.
Hovering over something would map back to your source tree, which (as you are building it) you would load up with any information that you want to display.
Maybe it's overkill, but it sounds like a fun project.
This sounds to be related to this question:
https://softwareengineering.stackexchange.com/questions/189471/how-do-ide-s-provide-auto-completion-instant-error-checking-and-debugging
The accepted answer of that question recommends this link which I found very interesting:
http://msdn.microsoft.com/en-us/magazine/cc163781.aspx
In a nutshell, most IDEs generate the parse tree from the code and that is what they stores and manage.
We have a proprietary file format which has embedded in it a product-code.
I am just starting down the path of "enabling the end-user to sort / filter by product-code when opening a file".
The simplest approach for us might be to simply have another drop-down in our customized Open File Dialog in which to choose a product-code to filter by.
However, I think it might be more useful to the end-user if we could present this information as a column in the details view for this file type - just as name, date-modified, type, size, etc., are also detail properties of a file-type (or perhaps generic to all files).
My vague understanding is that XP and prior Windows OSes embedded some sort of meta data like this in an alternate data stream in NTFS. However, Starting in Vista Microsoft stopped using alternate data streams due to their dependence upon NTFS, and hence fragility (i.e. can't send via file attachment, can't move to a FAT formatted thumb drive, etc.)
Things I need to know but haven't figured out yet:
Is it possible / Is it practicable / how to create a custom extended file property for our file type that expresses the product-code to the Windows shell so that it can be seen in Windows Explorer (and hence File dialogs)?
If that is doable, then how to configure things so that the product-code column is displayed by default for folders containing our file type.
Can anyone point me to a good starting point on the above? We certainly don't have to accomplish this by publishing a custom extended file property - but that seems like a sensible approach, in absence of any way to measure the costs of going this route.
If you have sensible alternative approaches to the problem, I'd be interested in those as well!
Just found: http://www.codeproject.com/Articles/830/The-Complete-Idiot-s-Guide-to-Writing-Shell-Extens
CRAP! It seems I'm very late to the banquet, and MS has already removed this functionality from their shell: http://xpwasmyidea.blogspot.com/2009/10/evil-conspiracy-behind-customizable.html
By far the easiest approach to developing a shell extension is to use a library made for the purpose.
I can recommend EZShellExtension because I have used it in the past to add columns and thumbnails/preview for a custom file format for our company.
I need some methods of storing and getting data from a file (in WIN32 api c++ application, not MFC or .NET)
e.g. saving the x, y, width and height of the window when you close it, and loading the data when you open the window.
I have tried .ini files, with the functions -- WritePrivateProfileString and ReadPrivateProfileString/Int, but on MSDN it says
"This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry."
and when i tried on my Windows7 64bit machine to read a ini file, i got blue screen! (in debug mode with visual studio) O.O
I notice that most other application use XML to store data, but I don't have a clue how to read/write xml data in c++, are there any libraries or windows functions which will allow me to use xml data?
Any other suggestions would be good too, thanks.
There is nothing wrong with .ini files, the only problem with them is where to write them. CIniFile from CodeProject is good enough class. Ini file should be placed in %APPDATA%/<Name Of Your Application> (or %LOCALAPPDATA%\<Same Name Here>, as described below).
EDIT: If we are talking about Windows family of operating systems from Windows 2000 onward then function SHGetFolderPath is portable way to retrieve user specific folder where application configuration files should be stored. To store data in romaing folder use CSIDL_APPDATA with SHGetFolderPath. To store data to local folder use CSIDL_LOCAL_APPDATA.
The difference between local and roaming folder is in the nature of the data to be stored. If data is too large or machine specific then store it in local folder. Your data (coordinates and size of the window) are local in nature (on other machine you may have different resolution), so you should actually use CSIDL_LOCAL_APPDATA.
Windows Vista and later have extended function SHGetKnownFolderPath with its own set of constants, but if you seek compatibility stick to the former SHGetFolderPath.
TinyXML is a popular and simple XML parser for C++.
Apart from that, you can really use any format you want to store your settings, though it's considered good practice to keep settings in text format so that they can be hand-edited if necessary.
It's fairly simple to write your own functions for reading/writing a file in INI or similar format. The format is entirely up to you, as long as it's easily comprehensible to humans. Some possibilities are:
; Comment
# Comment
Key = Value (standard INI format)
Key Value
Key: Value
You could use Boost.PropertyTree for this.
Property trees are versatile data
structures, but are particularly
suited for holding configuration data.
The tree provides its own,
tree-specific interface, and each node
is also an STL-compatible Sequence for
its child nodes.
It supports serialization, and so is well-suited to managing and persisting changeable configuration data. There is an example here on how to load and save using the XML data format that this library supports.
The library uses RapidXML internally but hides the parsing and encoding details, which would save you some implementation time (XML libraries all have their idiosyncracies), while still allowing you to use XML as the data representation on disk.
libxml2. I have seen quite a lot places where it is used. Easy to use and loads of examples to get you started and not a vast library as such. And in C, take it wherever you want.
pugixml is another good (and well documented) XML parser library. And If you like portability XML is a better option.
While INI files may not be the best format, I think you can safely ignore the warning MSDN puts on WritePrivateProfileString and ReadPrivateProfileString.
Those two functions are NEVER going away. It would break THOUSANDS of applications.
That warning has been there for years and I suspect was added when the registry was all the rage and someone naively thought it would one day completely replace INI files.
I might be wrong but it would be very unlike Microsoft to break so many existing apps like this for no good reasons. (Not that they do not occasionally break backwards compatibility, but this would cause huge problems for zero benefit.)
Ohhh My GOD? Have you ever thought of stright-forward solution rather then thinking of Super-Duper-all-can-do framework way?
Sorry...
You want to store two numbers between restarts???
Save: Open a file, write these two numbers, close the file:
std::ifstream out(file_name);
out << x << ' ' << y;
out.close();
Load: Open a file, read these two numbers, close the file:
std::ifstream in(file_name);
if(!in) return error...
in >> x >> y;
if(!in) return error...
in.close();
Libconfig is the best solution in C++ as far as I have tried.
Works multi platform with minimum coding.
You must try that!
I like the TinyXML solution suggested.
But for Windows, I like .ini even more.
So I'll suggest the inih library, free and open source on GitHub here. Very simple and easy to use - 1 header file library iirc.