From: Fred vS <fi...@ho...> - 2024-05-17 02:40:36
|
Hello everybody. Great news! Finally I find a way to save the canvas of a form, with all his child-components into a png file (or bitmap). Only the canvas is saved, even if the form is covered by other external forms. Here the trick (thanks to the wonderful BGRABitmap gem): ---------------------------- procedure tmainfo.saveform2png(const Sender: TObject); var btmp: tbgrabitmap; r: rectty; p: pointty; begin btmp := tbgrabitmap.Create(Width, Height); r.x := 0; r.y := 0; r.cx := Width; r.cy := Height; p.x := 0; p.y := 0; btmp.Canvas.copyarea(getcanvas, r, p); // The Trick! btmp.savetofile('aBitmap.png'); btmp.Free; end; -------------------------------- That opens lot of new possibilities ( Wayland, etc...) A zip file with a project demonstrating it is there: https://github.com/mse-org/mseide-msegui/discussions/62 Fre;D |
From: vasi v. <fu...@gm...> - 2024-05-17 05:34:09
|
That is awesome! On Fri, May 17, 2024 at 5:40 AM Fred vS <fi...@ho...> wrote: > Hello everybody. > > Great news! > > Finally I find a way to save the canvas of a form, with all his > child-components into a png file (or bitmap). > Only the canvas is saved, even if the form is covered by other external > forms. > > Here the trick (thanks to the wonderful BGRABitmap gem): > > ---------------------------- > > procedure tmainfo.saveform2png(const Sender: TObject); > var > btmp: tbgrabitmap; > r: rectty; > p: pointty; > begin > > btmp := tbgrabitmap.Create(Width, Height); > > r.x := 0; > r.y := 0; > r.cx := Width; > r.cy := Height; > > p.x := 0; > p.y := 0; > > btmp.Canvas.copyarea(getcanvas, r, p); // The Trick! > > btmp.savetofile('aBitmap.png'); > > btmp.Free; > > end; > > -------------------------------- > > That opens lot of new possibilities ( Wayland, etc...) > > A zip file with a project demonstrating it is there: > https://github.com/mse-org/mseide-msegui/discussions/62 > > > Fre;D > _______________________________________________ > mseide-msegui-talk mailing list > mse...@li... > https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk > -- Vasi |
From: Sieghard <s_...@ar...> - 2024-05-17 22:13:23
|
Hello Fred, you wrote on Fri, 17 May 2024 02:40:26 +0000: > Great news! > > Finally I find a way to save the canvas of a form, with all his > child-components into a png file (or bitmap). Only the canvas is saved, > even if the form is covered by other external forms. Very nice, and probabely useful for a few applications. (It certainly might have helped for documenting my msegui-Project from yonder yore, where I had to relay on an external program that wasn't always really reliable... But that project is "through"; it's still in use, but development's deceased.) I'm sure to test it, anyway. Maybe I'll use it to produce some "screen" shots of my example projects. BGut for now, I'm still about getting the "newdialog"'s "msefiledialogx" unit to work, mainly working on penetrating the insulation layer named "tfiledialogxcontroller". Nearly _everything_ that distinguishes it from its "x"-less counterpart can be fully handled from within the dialog form. But passing ANY layout or state information through that tough beast is nearly impossible besides doing it by passing a full, fully initialized, form altogether. As you might have noticed, that's what I have done for the basic file dialog anyway, and thus this would not be a big issue, wouldn't it require a nearly full rewrite of a number of ancillary routines like the "filedialogx" function and the whole "tfiledialogx" component. I'm yet irresolute what to do about that. The result probabely will look quite a bit different from your original, also because I took the freedom to modify some streches of code that could be replaced by a simpler function and a couple of definitions together with a table of elements. (BTW: are you sure of the naming of the file type ".dylib"? Or should that be ".dynlib", what seems more logical to me? Also, there are two occurrences of the - now obsolete - ".pyc" type. Which one is used?) Also, you wrote on Fri, 17 May 2024 15:33:59 +0000: > Does somebody knows SDL and have already used applications done with it > it? Not really (yet?)... > There is a other gem in MSEuniverse: > https://github.com/mse-org/mseuniverse/tree/main/sdl4msegui Looks interesting - I'm sure to want to have a look at it. Or is that just the old version of the "universe" web presentation "sdl4msegui.html" from 2018? There was even a set of units (.pas files) "sdl.zip" in 2012, seeminly structured a bit according to the "kernel" subdirectories for linux and windows. Is that what you're referring to? ... > But the demo is not out-of-the-box, it uses custom mse*** files that > needs to be updated. Should be doable, if it worked before. But is not SDL only or at least mostly for console / frame buffer use? > And before to maybe enter into a new battle, I would like to know if it > is worth it. It could perhaps help for "porting" msegui to Wayland, if anybody cared... Thanks for your information! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2024-05-18 00:19:01
|
Hello Sieghard. About "msefiledialogx", of course don't hesitate to adapt it as you wish, it's an honor for him. >BTW: are you sure of the file type name “.dylib”? Or should it be ".dynlib", which makes more sense to me? Hmm, that's Apple's logic. The suffix of a dynamic library on OSX is ".dylib". Yes".dynlib" is more logical and something shorter like ".dyl" would be fun too, but you know, taste and colors...) Fre;D |
From: Sieghard <s_...@ar...> - 2024-05-29 22:13:20
|
Hello Fred, you wrote on Wed, 29 May 2024 14:23:50 +0000: > Your latest corrections are comitted in the Sieghard branch. Thanks you for passing on. I hope it can be useful. > Have a nice day. Same to you. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Sieghard <s_...@ar...> - 2024-06-18 13:30:20
|
Hello Fred. So. Now I got something. The "msefiledialogx", of course. A version that DOES, mostly, what I want it to do. That is: - Multiple entry select for "listview" AND "list_log" display - "seamless" switching between displays (i.e. selections are kept) - mostly "standard" selection methods by mouse and keyboard In addition, as I had to rewrite quite some chunks of code to achieve this, I made a number of modifications: - consistent data management for file selection - "straightening up" a number of overly complicated processsing sections - simplify handling of icons for the "list_log" display - change display configuration to context menu (right mouse button) And it's STILL not finished, by far, yet, as I couldn't possibly have tested every (combination of) functions and settings possible. Nonetheless, I put the current version FOR YOUR TESTING AND CRITIQUE on my web site, along with the stand-alone "FlieRequesterX" sample application that can be set to make use of nearly all of the dialog's abilities. I hope you can get it to work, and, PLEASE, check it out thoroughly and give me feedback about your findings, and not publish it on github immediadietly. If you think it might be in a state where others can get it to work also, it might be of some help to publish, but only with a clear marking as "experimental". BTW, the code of the unit file is still overall cluttered with insertions, commented-out parts, comments, remarks and streches of inactivated or nor longer used old original code. This makes it certainly tedious to read and difficult to understand. ANY "final" version WILL have to be cleaned up thoroughly and possibly be rearranged a bit to help understanding. Well, and yes, the "stringgrid" component doesn't seem to be fully functional, as I surmised in my previous posting. Most call-backs aren't apparently working, and that seems to be the reason why you had to add that monstrous "oncellev" handler in the first place - is that correct? Anyway, here it is, as it is, for you to contemplate, evaluate, test and peruse, "newmsefiledialogx_nv0.zip". Not for publishing yet, though. Please report any problems you find and suggestions to improvement. Thank you for your kind help, and have a lot of fun! And a nice time as well, of course. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2024-06-18 18:06:42
|
Hello Sieghard. Many thanks for your last features-fixes for filedialogx. I will test it deeply asap and write you soon. Have nice days. Fre;D |
From: Sieghard <s_...@ar...> - 2024-05-18 16:10:30
|
Hello Fred, you wrote on Sat, 18 May 2024 00:18:53 +0000: > About "msefiledialogx", of course don't hesitate to adapt it as you wish, > it's an honor for him. Well, I got a little tired of the "work" by now. It's a bit tedious chasing after all the inconsistencies and issues caused by replanting the state variables, and there are a couple other issues to be fixed as well. In addition, some time ago alreadyI had found some places where the code could have been simplified apreciately by using appropriate data structures. Most of this is in place now, and it seems to - mostly - work, although I couldn't test all the implcations of the modifications. This specifically applies to the free-standing "filedialogx" functions and the "tfilenameeditx" component family for internal use. They probabely will have to be modified to create a "tfiledialogxfo" intance by themselves, as there's no good way to pass any layout or state information through the controller barrier. > >BTW: are you sure of the file type name “.dylib”? Or should it be > >".dynlib", which makes more sense to me? > > Hmm, that's Apple's logic. The suffix of a dynamic library on OSX is > ".dylib". Ok, if it is meant to be so, then be it so. I just wondered about the name. I put a new file on my web site, "newmsefiledialogx.zip", containing an INTERMEDIATE TESTING version of your modified filedialogx for testing and review, and of course to uncover problems that escaped me yet. If you can find some time to look it through, please post your critique and findings for me to fix the issues. I've included - as a subdirectory - a simple and yet unfinished, but mostly functioning test project named "TextView". As the name implies, it's just a simple program to inspect text files, and meant to make use of the file dialog in this case. Hope to read your findings soon, but don't hurry, and have a nice weekend! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Sieghard <s_...@ar...> - 2024-05-19 00:13:20
|
Hello Fred, you wrote on Fri, 17 May 2024 02:40:26 +0000: > Great news! ... > Here the trick (thanks to the wonderful BGRABitmap gem): However... I tried to include your great new trick in a simple program using the extended file dialogx, just to be able to provide an impression of the result. Well, it doesn't seem to work for me. Although, after a bit of adaptation, it does compile alright - the BGRA code seems to take over all of the graphics functionality of fpc and msegui combined - the resulting executable won't run. All I get is the message: An unhandled exception occurred at $000000000049B297 : EClassNotFound : Class "TBGRABitmap" not found $000000000049B297 FINDCOMPONENTCLASS, line 7125 of /usr/lib64/msegui/lib/common/fpccompatibility/mclasses.pas $00000000004984D5 READCOMPONENT, line 6222 of /usr/lib64/msegui/lib/common/fpccompatibility/mclasses.pas BTW, I DID modify the .mfm file to reference a "TBGRABitmap". I tried with the "bgrabitmap-master.zip" retrieved from github, version 1.2.0.0, according to the file "update_BGRABitmap.json" contained in the package. Is there anything else needed? It doesn't seem to need much of installation, according to its (vers sparse) documentation. (Running the Makefile gave no errors.) What's / am I missing? -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2024-05-19 05:21:41
|
Hello Sieghard. To use BRABitmap for MSEgui, do this: 1. Download BGRABitmap source from here: https://github.com/bgrabitmap/bgrabitmap 1. In project options tab Make/Directories: Add using your BGRABitmap source directory: ${BGRABITMAPDIR}/bgrabitmap 1. In tab Make/Make Options add this parameters: -dBGRABITMAP_USE_MSEGUI -dclass_bridge 1. And in your source, in the uses section add those units: uses BGRABitmap, BGRADefaultBitmap, BGRABitmapTypes, ... Here the updated procedure: procedure tmainfo.save2png(const Sender: TObject); var btmp, btmp2: tbgrabitmap; r: rectty; p: pointty; begin btmp := tbgrabitmap.Create(Width, Height); btmp2 := tbgrabitmap.Create(Width, Height, BGRABlack); r.x := 0; r.y := 0; r.cx := Width; r.cy := Height; p.x := 0; p.y := 0; btmp.Canvas.copyarea(getcanvas, r, p); btmp2.PutImage(0, 0, btmp, dmDrawWithTransparency); btmp2.savetofile('aBitmap.png'); btmp.Free; btmp2.Free; end; |
From: Sieghard <s_...@ar...> - 2024-05-19 15:13:22
|
Hello Fred, you wrote on Sun, 19 May 2024 05:21:32 +0000: > To use BRABitmap for MSEgui, do this: > > 1. Download BGRABitmap source from here: > https://github.com/bgrabitmap/bgrabitmap That's where I got it. > 1. In project options tab Make/Directories: > Add using your BGRABitmap source directory: > ${BGRABITMAPDIR}/bgrabitmap I did it accordingly, although not in the ide's project options as I'm mostly using my command line "make" script. This (now) can extract the project options from the .prj file, but can also take additional options for a casual modified compile. (It you were interested. I can, of course, put it on my web site for you.) One slight problem lies in the format of the unit references - you wrote the names with capitals, but the file names use lower case only. This inhibits Linux from finding them, and the compiler complains about wrong file names if one creates correctly spelled links. So, for Linux (and other unixen) the unit references should either be written with lower case letters, or the shell must be set to find files disregarding the letter case (bash "shopt -s nocaseglob", e.g.). Or the file names changed, of course. > 1. In tab Make/Make Options add this parameters: > -dBGRABITMAP_USE_MSEGUI -dclass_bridge Here probabely lies the cause for my failure: Although I set the first definition (which I derived from your code in your msefiledialogx unit), I didn't know about the second one. But sadly, doesn't work out, see below. > 1. And in your source, in the uses section add those units: > uses > BGRABitmap, > BGRADefaultBitmap, > BGRABitmapTypes, ... This was done also, in accordance with the example code I found from your units. > Here the updated procedure: Thank you very much. But right now, I haven't yet included that in the test compile. So testing has to wait a bit until the basic program works correctly with the BGRA graphics units. When I now tried to use the ide for building the project, I got the same error message, and a lot of additional lines below. The origin of the problem seems to be the declaration "tbitmapcomp1: TBGRABitmap;" of the dialog form, which isn't, and cannot be, reflected in the .mfm file, as the ide just doesn't provide such a component, and there is none in the "bgrabitmap" directory. Is it possible that one had to recompile the IDE with BGRA bitmapps enabled, to get access to the pertinent components and to be able to use them? Unfortunately, I couldn't find halp looking through the specifications of your bgra project files for your ideU, because there you refer to elements that I cannot associate with anything available, most prominently a number of refreences to subdirectories named "bgragui*". I cannot find anything corresponding to any of them anywhere. So it doesn't seem to be as straightforward to use that stuff as seemed from your optimistic presentation of the "simple" screen dump routine... Anyway, have a nice time, and keep up the good work! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2024-05-19 15:24:47
|
Hello Sieghard. Strange that it does not work for you. But, did you add the -B (build all) parameter? Without it fpc sometimes ignore some of the {$ifdef something}. It is a very old bug and till now it was not yet fixed, so better to use -B, mainly for the first compilation of the project. Fre;D |
From: Sieghard <s_...@ar...> - 2024-05-19 22:13:16
|
Hello Fred, you wrote on Sun, 19 May 2024 15:24:33 +0000: > Strange that it does not work for you. Strange also that there's the attempt to use a _component_ that isn't provided by the component library. and not even requested from the .mfm file, I think. And there's the explicit request for a BGRAbitmap from a compiler conditional that came with the original code. > But, did you add the -B (build all) parameter? > Without it fpc sometimes ignore some of the {$ifdef something}. Not exactly, but I _always_ did a full recompile, after cleaning out all the generated .o and .ppu files from the project. Shouldn't this be equivalent to using the "-B" compiler switch? > It is a very old bug and till now it was not yet fixed, so better to use > -B, mainly for the first compilation of the project. I know, and there's the other "issue" of the compiler recompiling the same units over and over even after minor modifications that don't affect those. But... today's machines (even though mine is several years old already) are fast enough to not be much of an obstacle with that... Well, I'll put that aside for now, as I found a couple of other errors and problems with the msefiledialogx, some of which at least I did introduce myself. Happy computing! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2024-05-19 22:38:45
|
Hello Sieghard. Ha, ok, I think I get it now. In the code of msefiledialogx.pas there are those ifdef: {$ifdef BGRABITMAP_USE_MSEGUI} It is because the msefiledialogx shows the rendered image on the bottom-left if you select a image-file in a directory. If you did not use BGRABimap on your application, the image will be rendered by the MSEgui.bitmap. But only some formats (png, bmp, gif and jpeg) can be rendered. If your application uses BGRABimap then it will be a BGRABitmap.bitmap that will be used and that covers nearly all the graphic formats that exist. Also the rendering is faster with BGRABimap. I have some graphics appliations that uses BGRABitmap and some msefiledialogx in it. At compilation, msefiledialogx will uses BGRABitmap for rendering of the lot of format image-files. Fre;D |
From: Sieghard <s_...@ar...> - 2024-05-20 22:13:22
|
Hello Fred, you wrote on Sun, 19 May 2024 22:38:29 +0000: > Ha, ok, I think I get it now. on't worry, don't hurry - I've put this aside as a "luxury problem" while catering to other things. > In the code of msefiledialogx.pas there are those ifdef: > {$ifdef BGRABITMAP_USE_MSEGUI} Yes, I realized that. I DID set the indicated definition for the compiler, and I even had copied the conditional from the uses clause to my main unit. > It is because the msefiledialogx shows the rendered image on the > bottom-left if you select a image-file in a directory. If you did not use > BGRABimap on your application, the image will be rendered by the > MSEgui.bitmap. But only some formats (png, bmp, gif and jpeg) can be > rendered. I saw the definition of the component, and that it is changed to a "BGRABitmap" by a compiler conditional. But this has no effect on the .mfm file, which still references the tbitmapcomp component from msegui. So this must create an inconsistency, which I even did try to circumvent by a modified .mfm file and its corresponding _mfm.pas - to no avail, the compiler STILL complained the same way. Thus, I must still have overlooked something, but as stated above, I'm not eager to pursue that further right now, that I'm chasing several effects of the plain "msefiledialogx" unit. And I found a couple "interesting" constructs, e.g. "theboolicon", seemingly a "penetration helper" for the contoller insulation, and in the same line probabely the use of the "fo.filename.tag" field. But my main issue is (was?) the loss of the filename history, in contrast to the simple "msefildialog" without an "x". I'm still chasing the cause... BTW, I also got stumbled by an effect that seemed to "randomly" delete the filename value, or not let it be displayed at program start. This seems to be caused by a construct depending an the filename.tag field that occurs at several places and simply clears the filname value if it's currently not showing a directory name, or something like that. After disabling this, the display seems to act "normally" (i.e. as expected by me). But I'll return to the BGRA issue when all these glitches are - seem to be - resolved. Have a nice time, and have lot of fun! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Sieghard <s_...@ar...> - 2024-05-23 00:04:23
|
Hello Fred, here's another intermediate report on the status of the "newdialogs"' msefiledialogx. It was a hard bit of work to make the "compact" diaplay work the same as with the plain original version. You made it work i a "horizontal" manner, which is very unusual and doesn't easily allow for multifile selection, as it always selects across all columns. But switching the display to the vertical arrangement always caused an Error 217 exit. The reason turned out to be an incomplete initialization during the first call to the fill function for the "list_log" field. It took me quite some attempts and much time to find this really not-so-obvious connection. Now that this is done, a similar hunt for the non-functioning multiple selection of the full display is on. This _might_ be somewhat more straightforward, as I found many places where its selection is simply discarded and the current cell defocused - perhaps there is a connection? After all, really many modifications of the code were neccessary, and a number of simplifications and shortcuts has also been introduced. In my opinion, it's somewhat more efficient now, and quite some unneccessary intermediate variables have been removed. On the other hand, it's now capable to run "stand-alone", and I made a according application that makes use of this feature, my often mentioned "FileRequest" program. For your reference, I've put a new version of the "newdialogs" units along with a special package named "newmsefiledialogx.zip" on my website. The latter contains the "msefiledialogx" component only, along with now two sample applications, the (incomplete) "TextView" program you got already, and newly an application named "FileRequesterX" comprising a stand-alone file selection program that can serve many different purposes. It will display a "help" list if called without parameters, explaining in short terms what it can do. I hope it can be useful, but should do as an example for the use of the file dialog component. Thank you for your support and patience, and have a good time! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2024-05-23 00:58:21
|
Hello Sieghard. Thanks for the updates for newdialogs(x). I did try your demo TextView.prj but at loading there is a exception message: List index (11) out of bounds. After clicking on OK, the application crash. For the demo FileRequester.prj, I did not catch how to use it and with what parameters. Could you give a example how to use it? Thanks. Have good days. Fre;D |
From: Sieghard <s_...@ar...> - 2024-06-19 00:13:16
|
Hello Fred, you wrote on Tue, 18 Jun 2024 18:06:28 +0000: > Many thanks for your last features-fixes for filedialogx. > > I will test it deeply asap and write you soon. Thank you for your kind support. Have a nice time! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2024-06-20 02:01:22
|
Hello Sieghard. I tested your latest fixes for filedialogx. Much better, selecting directories in the left panel now works. A small downside, when selecting an image file (bmp, png, etc,...) the preview is no longer displayed at the bottom left. I will test everything more thoroughly tomorrow. Fre;D |
From: Sieghard <s_...@ar...> - 2024-05-23 22:13:26
|
Hello Fred, you wrote on Thu, 23 May 2024 00:58:09 +0000: > I did try your demo TextView.prj but at loading there is a exception > message: List index (11) out of bounds. After clicking on OK, the > application crash. Interesting. I just unpacked the test project into a new directory, even using the packaged project file, compiled it, and it works without a problem. I get a file request dialog, can select a file from it, and on ok the file is loaded and displayed in a newly opened window. Of course, I _assume_, the newdialogs and their "ancillary" modified units (msestatfile, at least) are available? But otherwise, the compiler would probabely complain anyway. So, sorry, I have no clue here. > For the demo FileRequester.prj, I did not catch how to use it and with > what parameters. Could you give a example how to use it? Thanks. Did you compile it with the definition "plain_english" enabled? This might make the help display easier to understand for you. It explains all the options that it can take, and I tried to also give some clue as to what it can produce. The simplest use is to select a file and output its name on stdout. But you can also use it to execute a program with the selected file, or list of files, if set that way. You DO need to specify at least one option, except, of course "--help" or "-h", to display a selection window. If you use "-t" or "--title", followed by some name, it will show that as its titlle bar name and use it as the name of its stat file also. A more complicated example for a use is to select pictures to display is: $ FileRequest --fmask "bmp,gif,png,jpg,jpeg,svg,BMP,GIF,PNG,JPG,JPEG,SVG"\ --under-mouse --history --title "Select Pictures" --select <directory>\ --list --exec qiv Here "<directory> would have to be set to the directory you want to select the picture files from, and "qiv" is the name of the display program it will use. The "--list" option provides a list of all selected files as a parameter to "qiv", which can cycle through them on its own. And yes, the "--fmask" option provides the filter for selectable files. As you see, the order of options is not relevant, as they're parsed within a loop. And no, there's no non-option additional parameter, as the program's function is just to supply such parameters for client applications (or scripts). (But I just found it lacking somewhat on the "--exec" option, in that it does NOT allow for passing additional information to the called program. I shall add that...) If the above explanation attempt isn't sufficient, please ask again. Otherwise, I hope you may find a few applications for this kludge. Happy computing, and have a nice time! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2024-05-23 23:40:08
|
Hello Sieghard. OK, FileRequester demo works. I did try with FileRequest -t parameter. The newfiledialogx appears. Selecting directories from the left panel is ok appart when clicking on "/usr" icon-directory there is a error message: "List index (14) out of bounds". Also clicking on "Desktop" icon "List index (6) out of bounds". Other directories seems ok. Maybe it is related with the error I get with TextView demo. I would like to help, in the "original" filedialgx it is ok, but at first look I dont see what you changed that could cause this. Fre;D |
From: Sieghard <s_...@ar...> - 2024-06-20 22:13:21
|
Hello Fred, you wrote on Thu, 20 Jun 2024 02:01:08 +0000: > I tested your latest fixes for filedialogx. Thanks a lot. > Much better, selecting directories in the left panel now works. > A small downside, when selecting an image file (bmp, png, etc,...) the > preview is no longer displayed at the bottom left. Maybe, I didn't test that yet, as I found a more annoying problem: the FPC log10 function isn't really good at handling zero values... But of course, it SHOULD balk at that, and throw an exception. The point is, the msegui code catches that exception deep inside, and an application programmer has no chance to handle that with a TRY/EXCEPT block. But anyway, I DO think the better way is to do it the traditional way with a conditional, and that's what I did already. I might soon put the new version, in conjunction with some cleaning up of the "oncellev" method, on my web site. But I plan to also add the "shift-click" block selection method for the list_log display, which shouldn't be overly complicated. And, of course, I will check the preview display and hopefully get it to work again. > I will test everything more thoroughly tomorrow. You might make sure to check for a new version on my web site before, perhaps. Thank you again for your support and interest, and "hav a alot of fun" again. But don't let you distract to much. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Sieghard <s_...@ar...> - 2024-06-21 00:20:18
|
Hello Fred, a new version of the filedialogx is there. No more filesize 0 problem, a couple control functions "optimized", and picture preview re-renabled. Sorry, no shift-select action yet, too little time left from testing. (The preview was lost because it had somehow managed to escape to the listview display handling...) Success, and have a nice day! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |
From: Fred vS <fi...@ho...> - 2024-06-23 20:30:45
|
Hello Sieghard. I have tested your lastnewmsefiledialogx_nv1.zip. Wow, everything works perfectly now. Image previews, window positions/size and impressive multi-select with Ctrl + click. Congratulations, fabulous work. Many thanks. Fre;D |
From: Sieghard <s_...@ar...> - 2024-05-28 21:10:23
|
Hello Fred, this time not an update on the "msefiledialogx", but on the "db" unit modifications. As I just had an occasion to use the OSQLBrowser, I was again hit by an update problem I had found before (and addressed by a cautionary remark in the README to the sample programs). So I undertook to correct this problem, which amounts to the inability of the mse db units to correctly handle SQL object names that contain some special characters and so have to be quoted for use. I could successfully correct the problem at least for field names, which allows automatially generated database modifications to arbitraryly named fields, and also lets the browser sample applications update such records correctly. The modifications affect two units of the "db" subdirectory, "msedb" and "msesqlquery". Thus, I uploaded a new version of the "msegui_lib_db_patches.zip" archive to my web site for further usage (and,. hopefully, testing by others). Have good time, and happy computing anytime! -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- |