To avoid reinventing the wheel, I'm looking for some dialog wizard components/libraries that will simplify my job of importing CSV and similar text files into my Delphi/C++Builder application.
In other words, the user of our app can 'open' a suitable text file, and they can 'describe' through the UI how the columns are laid out and how the file columns relate to the datafields that our app offers.
Basic requirements:-
Handle different newline styles
Handle Tab, Comma and user-specified fixed-width columns
User definable column ordering with visual preview of results
Handle optional and mandatory columns
Extra goodies:-
Be able to save all settings as a 'profile' that can be easily reapplied later.
Try these two components
EMS Advanced Data Import VCL
EMS Advanced Data Export VCL
SMImport comes to mind : http://www.scalabium.com/
My text streams classes in the unit CsiTextStreamsUnt.pas (you can download the utility classes at http://www.csinnovations.com/framework_utilities.htm) provide the basic functionality to cover everything you need. All you would need to do is develop the GUI.
Related
I need to make an app that will let users select some options, click a button, and a separate compiled app is created. Is this possible? I am using delphi 7 and 2010.
Thanks for the replies. Here is a little more info.
It would have to be a graphical app and create a graphical app.
What I want is the user to fire up 'App A' (I originally made), be able to select some options (I apologize for the secrecy. I think this is a million dollar idea that probably 3 people may find useful :) then use the program to create 'App B.' 'App B' can then be distributed to end users and 'App B' is a single executable that includes a compiled app plus the configuration data. I don't care how, but I need 'App B' to be a single executable.
I wouldn't even need to use Delphi for the final compiled app. If there is some sort of "pseudo-compiler" that I can call from Delphi that would marry a precompiled exe and a separate config file into a single executable. That would work just fine as well.
Thank you for the replies and help.
Thank you.
I also faced a similar situation once. I had to produce an exe using my exe. I didn't want to go the compiling a source code because of complexity and license problems.
Lets call the parent app P and child app C. Also lets assume that whatever option C needs can be summed up in a config file (XML/INI etc). What I ended-up doing was:
Create P and C. Inserted C in resource data of P.
When user clicked the button after selecting options, P would extract C from its resource data.
Created an XML file containing the options selected by user and inserted it in C's resource data.
So whenever C will run, it will use the options given in the XML file stuffed in it. It looks like complicated and hacky but is reliable and simple. Do a google on "delphi embedding resource in exe" and you will find plenty of articles to do above.
It is possible. You will need a Delphi 7 (or compatible) compiler (command line at least) on the target machine. You will also need all the source code for the compiled application and that includes all the third party libraries if you use any.
When you have it all set just call the command line compiler (DCC32.EXE) with the proper parameters and paths.
You can use two approaches for this:
Call ShellExecute
Call CreateProcess
You will have more control over the execution with CreateProcess. Also you will have to watch out for legal issues and licences if you plan to use the compiler this way.
Given that the Delphi compiler can't be redistributed, one solution if the user has not a copy of Delphi may be to use a script engine (i.e. RemObjects PascalScript, but there are others), generate code for it, and embed that code (i.e. within a resource) in an executable that will execute it when launched.
Create a separate stub executable that implements all the logic you need, and that reads its configuration from its own local resources (look at the TResourceStream class to help you load a resource at runtime).
Include that stub executable as an RCDATA resource in your main app's resources when it is compiled.
At runtime, the main app can extract the stub executable from its resources when needed, save it to disk, and insert the necessary configuration data into the stub's resources using the Win32 API UpdateResource() function.
Without knowing more about why you think you need to do this, I assume you don't actually need to do this. Given the stated requirements, I'd simply have one app, written in Delphi, that looks for the existence of configuration data (.ini file, registry, etc..) In the absence of this, it presents a screen that "will let users select some options, click a button". Then the options are stored in a .ini file, and the rest of the program proceeds, making use of those options.
Alternately, I'd use some pascal scripting, such as provided by TMS.
If you are looking for a way to crank out custom-branded versions of an app, maybe use Inno Setup with a ResHacker step. i.e. gather requirements in Inno, spit out your .exe into a temp directory, use ResHacker to modify the .exe, copy it into the program folder.
I was wondering if it was possible to modify the default document library view "All Documents " to include the "Checked Out To" column.
I need this change to apply to any existing document libraries as well as any created in the future.
Thanks in advance
It is not recommended to change the OOTB features in SharePoint. I would make a new feature that contains the column in the default view. Just copy DocumentLibrary feature and make the proper adjustments and just use that one in the future for new document libraries.
To handle the already existing libraries I would write a bit of code (C#/PS) to add the column to the default view.
We have a multilingual site that is currently using 2 languages, but with several others coming soon. The site is localized primarily by resx files, but with some localized data in a database.
We need to find some tools to manage localization of the site - something that picks up on changes in resx files so translators will only need to translate new or updated texts.
Any ideas or recommendations? We're also interested in any articles about the logistics of localization if anyone has some.
I'm researching this area as we speak and I came across your post. I'm not sure if this is any help but in the past we used RCWinTrans for our localization. This was for mutiple C++/MFC products although it does support .Net . We would have a RCWinTrans project for each language/product we intended to support although you could have multiple languages in a single project. It kept track of state (i.e. not-translated, translated, changed, etc) and would allow us to export the strings to an excel spreadsheet which we could then send onto a translator. They would updated the spreadsheet and we would reimport the data.
Hope this helps, apologies if I'm on the wrong track and I'm teaching grandma to suck egss. I will be creating another thread today with a similar requirement to this btw, but with a few more snagettes - might be worth a look to see if I get any answers. Cheers, Roger
An idea might be to have all the localization data the database (or a localization database), this way one could build the localization tools/interface as part of the application and poyentially use it for many applications?
There is a free tool called Resource Translation Helper ( http://www.winking.be/resource-translation-helper )
Install it
Point it to your project directory
Export to excel (.xls)
Give the excel to your translaters and let them update the columns.
Import the updated xls file again
The tool creates also a file to map the resx translation to the excel rows. Don't remove that or you will not be able to import again.
Works very good, but backup your data before adjusting things ;-)
You cant try to use this Visual Studio extension https://visualstudiogallery.msdn.microsoft.com/2676967b-0516-4f5f-b312-6873e2f9d219.
It allows to export/import your project resources to/from excel and to add new cultures.
Old question, but I would like to add http://www.zeta-resource-editor.com/index.html
Free tool for .NET resource files.
This directly edits the resource files, no need to ex-/import.
Which is the simplest way to localize the registry keys based on the selected language of an InstallShield setup?
I am thinking about writing an VBS which sets some properties based on the selected language. These properties could be used from within the registry key dialog of InstallShield. But isn't there a simpler way?
Found a way myself.
Instead of writing a vbscript you can add two components. The first components adds the english registry keys and the second one the german ones. In order to use only the correct component during install you can set the condition of the german component to "ProductLanguage=1031" and the englisch component condition to "ProductLanguage=1033".
Thats all :)
Of course it is arguable whether the use of multiple components or a script which changes properties used by only one component makes more sense but by using multiple components you can create your registry keys through the designer. Using a script which changes properties will certainly lead to more errors since the script has to work and every property has to be set correctly. In my eyes its more simple by using the components way.
We develop a database application. The user asks for a new feature: Copy blobs into the clipboard such that Windows Explorer can paste them as new files. One solution is to save the blobs into a temporary folder and add these temporary files to the clipboard.
But I'm looking for a better solution. Is it possible to hook the paste action in Windows Explorer and save the blobs to the destination path by myself?
I've never tried it but I think it is indeed possible. Please take a look at the MSDN Documentation for Shell Clipboard Formats. CFSTR_FILECONTENTS and CFSTR_FILEDESCRIPTOR are the formats you are likely supposed to handle.
Additionally, I found an article at Code Project which provides a demo program: How to drag a virtual file from your app into Windows Explorer.
Update: An example written in .NET:
Creating something from nothing
Creating something from nothing, asynchronously
From the MSDN article Handling Shell Data Transfer Scenarios
Existing files should be offered with the CF_HDROP format.
Offer file-like data with CFSTR_FILECONTENTS/CFSTR_FILEDESCRIPTOR
formats. This approach allows the
target to create a file from a data
object without needing to know
anything about the underlying data
storage. You should normally present
the data as an IStream interface. This
data transfer mechanism is more
flexible than a global memory object
and uses much less memory.
Two other good articles to read from MSDN are:
Shell Data Object
Shell Clipboard Formats
When I first started working on using the clipboard to transfer files I printed off all three articles and read them several times.
Dealing with the interfaces can be quite involved. I have found two good libraries out there to help with this.
The The Drag and Drop Component Suite for Delphi. If you scroll down on the home page you will see some FAQs are good reading. There are also a lot of sample applications with the download. I think the AsyncSource demos should be helpful for what you are looking for. The suite is freeware with source. The code seems to be well commented.
I am currently using the Transfer#Once component from Quasidata. It is not free but is very inexpensive. I initially used Transfer#Once because at the time it was better supported than the Drag and Drop component suite. However, that situation has reversed itself. Transfer#Once does not yet support Delphi 2009. When I get around to moving my application I will probably switch components. The Transfer#Once code is included with purchase. Personally I found the Drag and Drop code to be much easier to read and follow.
I'd say that explorer does the copying to the destination files itself, so there's no way to directly write the destination files. This makes sense, because the names of the source files can only come from the application that copied the data to the clipboard, which need not be explorer. OTOH the names of the destination files may actually differ, because files of the same name could already exist in the destination folder, and only explorer can create the modified names for the destination files (like by prepending "Copy of " or by appending " (2)" to the base file name).
You will need to provide the clipboard format for the Windows Explorer so that it can paste the files. The documentation of standard clipboard formats suggests that CF_HDROP is the right one. With this clipboard format you would provide a list of source file names, but the files do need to exist of course, so you will need to save them to disc.
You could try to make the process as light-weight as possible, though. Usually when a user copies data to the clipboard it is put there immediately, whether or not it will be used for a paste operation. For your application that would mean that you would need to create the files and put the list of file names into the clipboard, every time. However, Windows does support a mode called Delayed Rendering, which is used exactly for such cases. Basically you put only an empty stub of the data onto the clipboard, and only when another application tries to access the data it will be requested from your app. So you could implement this in a way that only when the user tries to paste the files into explorer you would save them to disc and return the list of file names.
It's been a while since I toyed with copy/paste, but I'm pretty sure you can do what you're suggesting (insert the blob as a new file into the clipboard).
I seem to remember that depending on how you add to the clipboard you can specify what sort of data you're copying. I think if you get that data type right, you'll be able to paste as though you'd copied from windows explorer.
I'll try and dig out some more details this evening if I have a chance (I don't have all my bookmarks here at work)...
[Edit] Have a look at the wxWidgets documentation on drag and drop. That was what I'd been working with and it gives some hints about data types.
What are you writing in? Delphi?
[Edit2] I think this may actually be a limitation of Windows(?). It might just be the wxWidgets documentation, but there's a suggestion that you only copy filenames rather than the files themselves. If that's the case, you're going to have to ue your original suggestion of creating a temp file first :-(