I am working in C language and creating applications for an embedded device. These applications mainly
include capturing data and storing it into a database for performing an enrollment. This involves lot of
widgets like frames, buttons, check-boxes, radio buttons, widget list boxes, text boxes, entries, combo boxes etc. All these widgets are being created using the X library.
I have tried to make the application generalized using CSV files, having a list of all the widgets that the user wants to create and then creating those widgets accordingly based on the information mentioned
in the CSV file.
The CSV file that I am creating includes things like
Widget name
Widget type
Widget data input type/max length / min length
.....
..... etc.
Please suggest some other ways or how can I improve the current way itself?
I am also creating the DB by the information provided in the CSV itself. I can say that it's
a "Data Driven User Interface" approach. I need some suggestions. Please provide me
some good suggestions.
Platform: Linux, GCC compiler
Maybe not quite what you are looking for but WxWidgets has a format called XRC. It's windows described as XML: http://docs.wxwidgets.org/2.9.4/overview_xrc.html. Are you really writing your GUI in C? I guess that might be a constraint on an embedded product.
Anyway, you might get good ideas from the site. I haven't used it so no specific feedback is available from me.
Related
Vista introduced an interface: IFileDialog::SetFilter, which allows me to setup a filter that will be called for every potential filename to see if it should be shown to the user.
Microsoft removed that in Windows 7, and didn't support it in XP.
I am trying to customize the our Open file dialog so that I can control which files are displayed to the end user. These files are marked internally with a product-code - there isn't anything in the filename itself to filter on (hence file extension filters are not useful here -= I need to actually interrogate each one to see if it is within the extra filter parameters that our users specified).
I would guess that Microsoft removed the SetFilter interface because too often it was too slow. I can imagine all sorts of similar ideas to this one which don't scale well for networks and cloud storage and what have you.
However, I need to know if there is an alternative interface that accomplishes the same goal, or if I really am restricted to only looking at the file extension for filtering purposes in my File dialogs?
Follow-up:
After looking further into CDN_INCLUDEITEM, which requires the pre-vista version of OPENFILENAME, I have found that this is the most useless API imaginable. It only filters NON-filesystem objects. In other words, you can't use it to filter files. Or folders. The very things one would filter 99.99% of the time for a file open or save dialog. Unbelievable!
There is a very old article by Paul DiLascia which offers the technique of removing each offending filename from the list view control each time the list view is updated.
However, I know from bitter experience that the list view can update over time. If you're looking at a large folder (many items) or the connection is a bit slow (heavily loaded server and/or large number of files), then the files are added to the dialog piecemeal. So one would have to filter out offending filenames repeatedly.
In fact, our current customized file open dialog uses a timer to look at the view's list of filenames periodically to see if any files of a given pattern exist, in order to enable another control. Otherwise it's possible to check for the existence of these files, find none, but a moment later the view updates to have more filenames, and no events are sent to your dialog to indicate that the view has been changed. In fact, my experience with having to write and maintain code for the common controls file dialogs over the years has been that Microsoft is not very cluefull when it comes to how to write such a thing. Events are incomplete, sent at not-useful times, repeated when not necessary, and whole classes of useful notifications don't exist.
Sadly, I think I might have to give up oh this idea. Unless someone has a thought as to how I might be able to keep up with the view spontaneously changing while the user is trying to interact with it (i.e. it would be awkward to go deleting out entries from the list view and changing the user's visual position, or highlighted files, or scroll position, etc.)
You need to initialise the callbacks for your CFileDialog. Then you need to process CDN_INCLUDEITEM notification code to include or exclude items.
You can also check this great article. The author uses some other approaches in addition to callbacks
As you have already discovered, starting in Windows 7 it is no longer possible to filter out files from being displayed based on content, only file extension. You can, however, validate that the user's selected file(s) are acceptable to you before allowing the dialog to close, and if they are not then display a message box to the user and keep the dialog open. That is the best you will be able to do unless you create your own custom dialog.
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 am looking for a good java library to manipulate box, arrows and labels in order to dynamically create and fill diagrams like the following and render them to a png :
Another example
I can create a static template to be filled later, but I will need to dynamically create labels for every box and edges in the diagrams.
For now I have tried using batik to manipulate an svg template but creating multiline labels for the edges is proving quite complicated. The SVG way with batik seems to force me to create 1 text object for each label line with absolute positioning for each which is a real pain.
I would like to be able to define the label specifying only the text and the link they relate to, eventually some hints as to how it should be placed and let the library place them.
Any suggestions ?
If this is in a commercial scenario, the Java graph drawing library yFiles can be a good match for your requirements:
You can use a convenient API to create and style your diagram and automatically layout the diagram with lots and lots options to constrain the resulting layout to suit your needs.
Multi-line and (simple) HTML labels are supported out-of-the-box.
Also you can export to PNG (as well as other pixel based image formats) and vector graphics formats like SVG, PDF, EPS.
This can be done both in a regular Java (Swing) application as well as in a headless environment (e.g. to create images on a server and to send them to a web-based thin client dynamically).
To get a feel what can be done using that library, I suggest you take a look at the freely available graph editor application "yEd" that is based on yFiles and lets you try out the above steps in an interactive manner.
(Disclosure: I work for yWorks, but on Stackoverflow I do not represent my employer.)
This may seem like a very strange question but is it possible to generate a Qt Designer form (.ui) from a Qt object, say something that inherits QWidget?
My plan is to build a simple dynamic form in code as the user picks what stuff they want e.g fields, type of control and then dump out a .ui file so that they can tweak the layout if needed after.
The code will then use the QUiLoader class to reload the ui file and show the modified or not ui file.
The Qt-Introspection tool GammaRay can save dialogs from the AUI (Application Under Inspection) to .ui files in its latest version, IIRC.
Since QWidget inherits from QObject, it gets all of the dynamic property inspection QObject provides. QObjects (and QWidgets) also naturally arrange themselves into trees (see QObject::parent and QObject::children). By following the tree of widgets, and getting the properties of each one, you can generate an xml .ui file containing the basic info about each control.
Working out the signal/slot connections from a pre-established form might be a bit more tricky, since there doesn't seem to be any way to get information on them besides QObject::dumpObjectInfo but for the program you describe in your question it's easy enough to keep track of them some other way.
Let my just clarify something, Qt Designer has a WYSIWYG user interface that creates a Qt Designer form in xml format, which is then converted to C++ code at compile time. And you're asking if one can do this backwards?
Yes, i do think it is possible, since Qt Designer Forms are just xml anyway. You can make an application that accepts C++ code, specifically the code used for the complete declaration of a class, then translate the PROPERTIES of the class into their corresponding xml code. This would involve a lot of work, in which at that point, i personally don't see the point anymore.
edit: this project would require you to reverse engineer Qt Designer. but yes, it is very possible.
not that way. As you remember, UI-file is the source code for generating appropriate .cpp-code at compilet-me. Gui-loader is a part of point-to-implementation pattern, which helps to reduce amount of compile-time.
You could also embedd Qt Designer into your own code using the designer module. You need to add CONFIG += designer to your .pro file.
Please take a look at the designer module here: http://developer.qt.nokia.com/doc/qt-4.8/qtdesigner.html
I'm trying to find out if there's a way to embed an editable text cell in a PDF generated in a Qt application. I'm currently using QPrinter to generate the PDF, but if there's another library that could do this, that would be fine. The environment is limited, though, to C or C++, so libraries like iText are out. In terms of form capabilities, this pdf,
http://examples.itextpdf.com/results/part2/chapter08/text_fields.pdf, is a good example with the exception that I don't need a password text field.
Thanks,
Frank
This may not be terribly helpful, but I'll throw it out there anyway.
wkhtmltopdf is based on QTWebkit.
One of its command line options is to convert HTML fields into PDF fields (off by default).
There's almost no pdf-related code within wkhtmltopdf. Certainly nothing dealing with fields. Something upstream is doing the PDF conversion for them.
So find out what that "something" is and you're golden.
EDIT: That or spend a lot of time writing JNI wrappers for iText. :/ Having done so myself, I can say it'd be much more interesting to write a JNI generator tailored to iText, but far more practical to write a Java app that uses iText and then make JNI calls from your C/C++ app to pass the data it'll need and retrieve any response.
The form field borders are a part of the page, not the field itself. Odd, but that's not the first time I've encountered it. Our own software, LiquidOffice, used to generate fields with backgrounds AcroForms couldn't support the same way (now we use an icon-only button).
Those Real PDF Fields have their visibility flags set to "visible but doesn't print" within the pDF. I doubt wkhtmltopdf will let you control that directly. Patch time.
BUT, you could make a second pass with some PDF manipulation library to go through and change the visibility settings on your fields. I'm partial to iText, but there are many other fish in that particular sea.