Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Tue, 14 May 2024 14:01:30 +:

> Hum, sorry but I dont catch what you mean.

Well, the matter IS a bit convoluted... I was probabely side-tracked and
got lost a bit in the intircasies of statfile handling...

> Here, with the "original" filedialogx, when you change the layout (and
> assigned a stat file for the component), it is saved. Of course the

Yes, I could reproduce that, and now I can also produce that with the
working version (!) of my "newdialogs" filedialogx. But only if it's NOT
called as a stand-alone form, yet. I WILL have to pursue this further, but
I think the remaining problem can be solved.

> position is saved too. So, if you want to assign a custom position, imho,
> the easier is to use tfiledialogxfo.oneventloopstart() and change the
> position there:

Well, that's not the reason. My previous problem was caused by something
quite primitive - in the course of testing different approaches, I had
simply lost a function setting an arbitrary filename for the statfile, and
kept trying to "convince" the code to save to the right file at several
other places. Stupid attempts, but I missed the primary cause all the time.

> Something like this (of course dummy code):

Thank you for your attempt, but it's not needed to dig so deep.

> But sureley I miss something.

THe one who missed something was me in this case.

But I still want to plea for a measure that obviates the, not just dupli-,
but even multiplication of the layout state values (not just variables, as
some of them are GUI elements) through the introduction of a call back from
the form to the controller. This looks much cleaner to me, and it keeps the
structure much closer to the original file dialog code.
Still, there seems to be quite a bit of work to be done yet, but I will
continue to get it running the way I want.

Stay tuned! Best wishes for all your undertakings!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

I have a question concerning your extended filedialogx.

I've run into severe problems with its statfile handling. It seems to me
that saving the layout dependent settings simply cannot work. This concerns
such things as display of icons, places column and even the settings bar
itself. They are meant to be written to the statfile by the
filedialogxcontroller when the dialog is closed. THe values of the form
elements are meant to be passed by separate variables defined in the
controller, but they cannot be set before the time when the controller's
writestat functions execute. This means the current values will never be
written to the statfile, although the controller can correctly _read_ the
old values every time when executed, and will thus always present the state
when the application was designed. That was - perhaps - fine for the old
dialog structure, where no user mede modifications were intended anyway.
It is a severe road block for "my" newdialogs, where this ought to be a
major feature.
There seem to be several possible ways to resolve this issue. One is, of
course, directly changing all of these variables immediately if they're
modified by the form; this could work already, because I had to add a
reference to the controller anyway. But I would like to avoid this heavy
duplicating of data and the requirement to carefully keep track of all
interdependent instances and the error potential of missing any of them.
Another measure might be to simply giving the controller direct access to
the form. Totally contrary to the naming, the controller has NO CONTROL of
the form it shows! Even though it can be created by its "execute" function,
there's no relation to the form's contents except only within this
function. And, interestingly, as of my observations, the statwrite call
that occurs there takes places immediately when the form is closed and way
before the layout variables are modified for a write back action that won't
happen later.
A third resort from the dilemma could be to introduce a call back into the
filedialogxcontroller letting the form insert its own statwrite (and -read)
function for these settings, which even would make the duplication of the
pertaining variables expendable, also removing the neccessity to constantly
assinging these values to and from their shadow copies.

And now to the begging question: What Do You Think?

Happy computing!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

might I present a stupid suggestion for handling msegui branches?

I always wondered why Martin put his library components into a SUBdirectory
of the real "lib" directory. And as I supposed him to have that done on
purpose, I came to the conclusion he might have done that to allow for
sepecial PARALLEL branches besides the "common" area, which probabely was
meant for those parts that should be - as the name suggests - COMMON to all
the project's library units covered by the whole system.
I even had used that for some time to place my "newdialogs" beside "common"
and address it through some project options (Fu definitions). Putting these
in a place where they are accessed _before_ any of the "common" branch, the
compiler would resolve any requirements from there and later ignore the
"original" definitions or nits from "common", as intended.
This could be a method to provide several regularöy distributed branches,
as well as a means for any user working on one or even several large
projects to keep his own librarie's code easily accessible, yet still on a
level where it belongs.
(And, of cousre, the "Fu" definitions also work for other locations on a
developer's machine, allowing him to access several components from
different sources.)
As I stated above, just a silly suggestion.

Happy coding, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Thu, 9 May 2024 11:23:59 +:

> Indeed, I just have tried to compile PSQLBrowse.prj for Windows and I get
> the same error message.

As I found out, this is because that's a Unix-only unit and not applicable
on and for Windows.

> If removing "cLocale" in uses section of SQLForm.pas then there is a
> other error:

> fontlist.pas(297,4) Fatal: Syntax error, "INTERFACE" expected but "END"
> found

Well, that's because on non-Unixen, this unit evaluates to an empty unit,
although even devoid of the - seemingly - required statements "Interface"
and "Implementation". I added these in an "else" clause of the encompassing
compiler conditional to "keep the compiler happy", as you use to say.

> Imho, PSQLBrowse.prj needs some tweak to work for Windows.

Yes, certainly. DIDN'T I state that I can only test it on Linux? Currently,
I've not even an emulator that does work, and no functioning "wine" as well.
Thus, anyone wanting to use the units on Windows has to test it himself,
sadly.

> PS: Compiling for Linux is ok (but i did not test it because I dont have
> libpq.so installed).

It would have happend the same with the SQLiteBrowser, they're very similar.
Anyway, I put the modified version on my web site, so at least these two
issues should be resolved that way.

Have a lot of fun...

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

this is just a short note to inform you and all users that there are new
versions of the "newdialogs" and "FileRequest" 'packages' on my web site.
The modifications are very minor, just a formatting correction for the
"newdialogs" and enabling the "return" key for terminating the "X" version
of the "FileRequest" program to accept the current selection.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Wed, 8 May 2024 11:42:15 +:

> There is also a problem with moving the window by clicking on the form,

Yes, this function was in error. Reason was a wrong use of the placement
code after the "keepOnScreen" was modified in the course of the development
of the "newdialogs".
The new version on my web site has the, after all, very simple correction.
There is also a new version of the "newdialogs" with a couple minor
changes, and a new example application named "FileRequester".
This is a stand-alone version of the "msefiledialog(x)" dialog from the
"newdialogs" meant for use within scripts to provide file selections or
even for "self-contained" applications like viewing pictures, videos or
selecting files for processing by other applications that can be called
from within it. Have a look on the "README" file to see what it provides.

Have a pleasant 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Wed, 8 May 2024 11:42:15 +:

> But maybe you did not see the screenshot when resizing MSEClocK.
> I will try to add it as attachment (maybe sf will accept it now).

The screenshot worked as an attachement, but it didn't really help.

> There is also a problem with moving the window by clicking on the form,

THIS is the explanation for my failing to reproduce your problem correctly.
I just did the (resizing and) moving the usual way by clicking and holding
the mouse button on the window TITLE BAR. This works witout any problem,
probabely because it is executed by the window manager.

> holding the button clicked and trying to move the window with the mouse.
> The form starts flashing and is placed in a random position.

But the extension intended to allow for MOVING (not resizing) the form,
specifically when no border ("window decoration on Linux) is used, provokes
the erratic movement you descibe, and it often even "loses" the window at
an unexpected position. I don't really remenber where the code for this
function emerged, I think you posted it here, even, but it didn't seem to
behave that way when I implemented it. This was a long time from now, and
as I don't really use the MSEclock program myself, I didn't regularly
inspect it for such - seemingly newly acquired - quirks. It might even
have to do with the function "keepOnScreen" that should make sure dialog
forms aren't placed outside the display area. Although this was moved to
the "msedialog" unit, I did also use it for the form-internal mouse
positioning. It does seem to not be really suitable for that use.

> Maybe both resize and moving form problems are related.

No, the sizing effect is indeed intended so, but the moving problem is
definietely not. I'll investigate the cause and try to reolve it. I'll give
you notice.

Thank you for reporting, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Tue, 7 May 2024 13:19:32 +:

> There is a little problem with MSEClock window what not redrawn correctly
> when resized.
> If resize the window (and change only the height), the window isn't
> redrawn properly. If clicking into the window, then it is redrawn
> properly.

Yes, that's intended. The window resizing is explicitely made to maintain a
constant aperture ratio, i.e. width-to-height ratio. And the decisive
parameter for setting the absolute size is its width, meaning you have to
change the WIDTH to change the size. If you want, you canchange this, but I
found the resulting display mostly not so good looking, prompting me to
introduce that little quirk to keep it "pleasant"
So no measures from my side here, at least if I understood you correctly.

> Also, only with Windows 64 bit, compiling MSEide with msegui-sieghard
> branch, there is that error:
> 
> mpqconnection.pas(1264,20) Error: (4004) Variable identifier expected

Thank you for reporting. That's indeed interesting, since that same
statement compiles without problem under Linux with fpc. Indeed, it does
NOT compile with the "ar8ty" cast, but produces the DIFFERENT error message
'Error: Identifier not found "beton8"'.
So this most probabely is a Windows specific problem, where the "currency"
type seems to be defined slightly differently, and where the endian shuffle
function "beton8" possibly is defined differently, with another parameter
signature, probabely.
It might be neccessary so to introduce a system dependent compilation
conditional to provide the correct type coertion expression.
(BTW, the FPC "ref.pdf" documentation text says toward this:
"The currency type is a fixed-point real data type which is internally used
as an 64-bit integer type (automatically scaled with a factor 1), this
minimizes rounding errors.". So this is not exactly defined - and there's
no type definition to be found in the FPC sources, even - and seems to be
compatible to an int64 on Linux only, but not on Windows.)
Perhaps the following might do, at least for FPC:

// Added for recent postgresql versions (28. Mar 2024 22:54:58):
{$ifdef FPC}
 {$ifdef WINDOWS}
int64 (ar8ty (cur)):= beton8 (pint64 (currbuff)^);
 {$else}
int64 (cur):= beton (pint64 (currbuff)^); // point here
 {$endif}
{$else}
int64 (ar8ty (cur)):= beton8 (pint64 (currbuff)^);
{$endif}

This will not help for a different Pascal compiler, but that's probabely
not really been tested already at all...

I hope this gives you sufficient, though possibly not satisfying, answers
to your requests,

Thank you again for your information, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Sat, 4 May 2024 01:04:18 +:

> Many thanks for the fixes, they are commited/pushed to the sieghard
> branch: https://github.com/mse-org/mseide-msegui/tree/sieghard

Thank you for publishing.

> Will test it deeply (and thanks for the fix in filedialogx.pas too).

I hope they work out for you and everyone who attempts to use them.
The "newdialogs" are still experimental, don't you please forget.
BTW, the fix is not in the filedialog, it's in the basic modified version
of the "msedialog" unit, and also adresses the blinking problem, which was
the real culprit.

Keep up the good work, and enjoy the weekend!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Thu, 2 May 2024 22:55:16 +:

> I haven't jumped into your code yet but the same crash appears when you
> try to free an object that hasn't been created yet.

Thank you again for the report - although this doesn't seem to be connected
to the REAL underlying problem, it did certainly pique me to investigate
deeper. And also to observe the system independent parts more closely.
But finally, the real cause was something quite unexpected, only caused by
an oversight from my part. I reused - misused - a data structure defining
window properties that "is already there", but not fully used, to allow for
passing more information. This worked - but only for the most part. And it
DIDN'T work for that part that was the least to be suspected, the case when
no specific positioning was to be done. In this case, a false flag (dp_none,
equivalent to "fo_main"!) was set, and this did lead the window management
functions to clear all of the application's windows when just the dialog
was closed. The other placement options do work correctly and did before,
as they have the same values as the equivalent original ones.
So the remedy for this big issue is a very simple minor modification in the
initialization code that just doesn't set the flag when not needed...
The new version on my web site contains this correction, in addition to the
addition of a new "DialogPlacement" variable for the file dialog controller
which allows to programmatically specify where a file dialog should be
shown.
As a minor aside, I put a patched version for the linux "mseguiintf" unit
(file "mseguiintf_patched.zip") there, in case you wanted to check it out.
It has the modification that seems to avoid some "not decorated" errors,
and at least reduces the long delay before they appear, should one occur
anyway. It also suppresses the Xorg gui error caused by a false call for
setting the X input focus in such cases. But that's just a minor problem,
usually without consequences, except for those possible sporadic "not
decorated" messages. It might just not hurt...

Thank you again for your support and information, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Thu, 2 May 2024 22:55:16 +:

> I haven't jumped into your code yet but the same crash appears when you
> try to free an object that hasn't been created yet.

This might be an important observation, thank you for reporting.

...
> Yes, there are problems with Windows too.

Which relocates the problem from the X11 interface units to something
deeper in the system... not making it easier to resolve, though.
But anyway, thank you also for reporting this.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Wed, 1 May 2024 21:42:39 +:

> About newdialogs: the position of the dialogs are much better now, many
> thanks for this great feature.

Yes, that's the good point, it mainly works now.
BUT: DON'T FORGET - I DID say, they're experimental yet! Didn't I?

> But there is a problem with the tfilenameedit component that uses the new
> tfiledialog.

Yes, there are a couple of problems with this beast. I _suppose_ it's
mainly caused by the need for using this weird controller thing, that just
serves to introduce another layer of complexity and seals off the final user
interface from the calling program. As I wrote in my parallel message (you
might not have read it when you wrote the above mentioned), there IS a
deep-lying, well, "effect" causing parent forms to be affected adversely,
mainly when closing such a dialog. Debugging these things seems close to
impossible, because the pertaining functions are used for most every action
dealing with program execution, so breakpoints are impossible to use, and
following the flow of execution wildly jumps through most of the kernel
(gui) code. It might be just a little quirk in the focus handling I found;
on Linux, Martin opted to always return the focus "to parent", even when
there isn't even a parent window. I _suspect_ that this could be coupled to
the "blinking" effect, which occurs because all the application windows
seem to be destroyed and rebuilt again when a "newdialog" terminates.
(But X11 error handling is implemented in a rather, err, overly optimistic
manner, i.e., when an error has been found and been "resolved", the
affected functions still return an "ok" result anyway.)

BUT a question here - and this is a VERY important one:  Does this blinking
(and possibly all the other adverse effects too) also occur under Windows?
If it didn't occur under Windows, I might be on the right track with the
above assumptions, otherwise, the problem might even be rooted deeper still.

> You may try with MSEide, compile it using your newdialogs.
> Run Mseide and click on menu Settings/Configure MSEide.

Yes, I did that, and I found weird behaviour myself. That's why I wrote my
last message, and that's a complete no-go for freely published code.
Experimental is in order, maybe there's someone who can find the cause of
the problem quickly, faster than I can. But it HAS definitly to be made
clear that there IS A PROBLEM (and probabely a couple more).

> Maybe you could take a look?

I'm about it (besides some other tasks, of course), but I'm not really
optimistic to have a solution fast.
BTW, the other modifications should be unaffected, i.e. the db units and
the stat file extensions, which are just minor patches anyway.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Wed, 1 May 2024 15:58:37 +:

> There is a new branch with the Sieghard newdialogs, statfile fixes and
> extended db

Thank you, Fred, for publishing all of these. I hope there will be some
response and critique, allowing to improve the stuff.
Indeed, there's one problem with the "newdialogs" I found, but didn't have
the time and opportunity to test on other platforms but my old Linux box
running the openbox window manager: Everytime one dismisses such a dialog,
it also blinks the main (or maybe calling) form of the application, and
sometimes it stays off altogether, only complaining about a "not decorated"
problem.
Investigating that, I found a "waitfordecoration" call in the
"kernel/linux/mseguiintf.pas" unit which seems to be superfluous, as
everything seems to work flawlessly without it, without any recognizable
problems concerning window decorations.
Sadly, I wasn't able yet  to find anythimg relevant about the blinking
issue, as it's nearly impossible to follow the intircately convoluted path
of execution through the pertaining, deeply entrenched and constantly
traversed, window control functions. It's literally so that after setting a
breakpoint there at some interesting point, you cannot run the program
normally any more. Most any action opening any smallish subwindow will ALSO
use that function, triggering the breakpoint and obviating the attempted
action...
But the culprit has to be something in conjunction with producing the
window decorations, as the dialogs work correctly with window decorations
disabled. Which isn't really useful, as this hampers one of the main goals
of the "newdialogs", providing free and self-controlled positioning and
sizing.
I'll continue to pursue the issue further, but I'm afraid that it will take
ample time yet. I'll report here what I can find, and of course, when the
issue was solved, may have been solved...

Thank you again, and keep up the good work.
I hope you could enjoy the holiday

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Tue, 23 Apr 2024 21:03:50 +:

> I tried the newdialogs components on Linux and everything seems ok, same
> for the stat files. For db files, because I don't know how thoroughly to
> test it, it's on the to-do list.

Fine to read that everything seems to work for you too, and thank you for
the time you spent on reviewing and reporting.

> Started a discussion on Github-mseide-msegui site and added the zipped
> files from your site:
...
> It would be great if other people try it on other OS too.

Yes, that would be good in any case, and even more so if mseide-msegui
could thereby get some publicity and perhaps a few new users.
BTW, I recently got notice of the CVE (Common Vulnerability Evaluation)
lists from ? That's a HUGE collection of software
vulnerabilities against intrusion and misuse, ranging from 1999 till
"today". They're available on github too, providing all the records on
. But beware: the zip file
is over 300 MBytes in size! I mention that because I was curious what might
be on record for Free Pascal, Lazarus and, of course, mseide-msegui.
Well, the result is very satifying: There's NOTHING to be found.
(But, of course I hope that's not just because there's close to nothing
around in use built from any of these...)

> For all the new DB things (SQLiteBrowse.zip, PV_Data.zip,PSQLbrowse.zip),
> I will jump into it asap.

You can check out the SQLiteBrowser quite easily by rummaging about in your
Firefox and possibly Thunderbird profile directories. The mozilla programs
like to store a lot of data in .sqlite files, many even keeping more than
one table per file (where a file is equivalent to a "database" for SQLite).
And you can immediately use the sample database .sqlite file from the
"PV_Data.zip" file. And perhaps some other user can modify the PSQLbrowse
program to work with maria db aka mysql? I just don't have a use for it,
and thus I haven't installed it. (And my backup disks are prone to overflow
anyway nonethess I try to keep my disks mostly uncluttered...)

But don't hurry, take your time, do thoroughly whar you do, and please
report problems timely so I can fix them. I realize that this is a lot at
once, so again, don't hurry.

After all, I wish you all the best and always success.
As martin used to say: Have a lot of fun!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

well, now at long last I've been able to upload the files pertaining to my
latest undertakings. It took me a while because of a modification of my
hoster concerning the access to their "control panel" and my web site data.
Now you can again find the latest files at the usual address. There's quite
a number there, now, because I separated them into independent components:

newdialogs.zip of course, the "new dialogs"
msegui_memorystatfile_patches.zip  extented "msestatfile" unit
msegui_lib_db_patches.zip  a couple patches for the db units,
   relevant mostly/only for Postgresql
MSEclock.zip   the good old MSEclock updated
PSQLbrowse.zip browser for Postgresql databases
SQLiteBrowse.zip   similar browser for SQLite databases
PV_Data.zipsome sample data for database testing

All the sample programs rely on the "newdialogs", although they should be
adaptable to use the "traditional" ones also. The db unit patches are
required only for the PSQLbrowser, to allow for Postgresql's additional
"interval" and "money" datatypes. SQLite doesn't know such, so it doesn't
need the modifications. "PV_Data.zip" contains a SQLite database file of
one year's worth of measurements of a PV installation, which can be used
to produce some nice graphic displays. It also contains a dump of the same
data for use with Postgresql or other SQL-based database systems.
You can peruse the sample database data as you like, even publish them, as
long as you don't disclose their source. For themselves, they should be
sufficiently neutral and anonymous.
Of course, the patch fles and the "newdialogs" are meant for consideration
for integration into msegui, and I'm awaiting your comments and requests
for modification.
Finally, the sample programs are meant just as such: examples for some of
the functionality of msegui and how it can be used to produce something
(hopefully) useful...

Thank you for your consideration, and keep up the good work!

(And please take my apology for the fuss about my misunderstandig of the
ide source file handling.)

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Thu, 18 Apr 2024 21:26:19 +:

> I apologize for the late answer.

No reason - it's not that urgent anyway.

> >The therein mentioned  
> projects are mainly working now, and I've also produced a SQLite browser
...
> Thanks for this great addition, I will test it deeply asap.

Well, they're probabely not that great, though they might serve as simple-
minded examples. They're somewhat centered around the "newdialogs", but,
with "a few" modifications, might be made useable with the standard dialogs
also. But I've not tried that and thus don't know how to do it.

> >But I've a BIG gripe to present: At least with the current ide,
> >debugging  
> has evolved to a nightmare.
> 
> I am sorry but I cannot reproduce (or understand) the problem.

Yes, I can imagine, now. Especially when you're using a windows system for
your work, you might not even be able to set up the ide to produce the
problem. I'm working - exclusively - under Linux (I specified my system in
my latest posting). As I'm a lazy gui, I put a link to the "newdialogs"
directory in the current working directory to have an easy access to units
that might have to be modified. And when I'd opened a file from this link
to modify or place a breakpoint, that's when the editor gets confused. It
doesn't recognize that a file it attempts to load from an internal request
that that's the same file, probabely because it doen't resolve the link
(although there are msegui functions for that, as I saw) and only checks
the file path (which is reasonable). Thus, the problem essentially turns
out to some amount of misuse, caused by, kind of, (my) overly optimistic
assumptions concerning the abilities of the tool set used.

> Could you, please, test your project with the latest mseide from Martin:

I realized that when I did this, and found the same, well, effects
occurring even with the original "historic" ide. This led me to a bit
further thought and investigation, and so I found the REAL cause for my -
thus self-inflicted - annoyance. So, there's no fault with the ide.
One might just wonder whether it might be of use to warn the user when he
attempts to load a file of the same name as one already open, to avoid HIM
getting confused what he is working on. Or, on Unixen, always fully resolve
paths for comparison during loading to avoid multiple openings. This might
even be appropriate in cases where one sets breakpoints in an indirectly
opened file that the debugger recognizes as part of the project (and that
even gets marked for code referencess (blue dots) and breakpoints (red
dots). That's probabely what caused my confusion in the first place.
After all, this was a false alarm only, and everything works as intended,
except when a nosy user attempts to outsmart his tools.
So I hope I didn't cause you too much inconvenience and could finally
clarify the cause.

In the end, I have to thank you for your help and patience,
and I wish you a nice and trouble-free weekend.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

this is a supplement to my previous posting here. The therein mentioned
projects are mainly working now, and I've also produced a SQLite browser
application similar to the Postgresql one. My "newdialogs" are mostly
working as well, although there's one annoying effect left, making the main
form "blink" for a moment when one is closed. I hope to get this eliminated.
But I've a BIG gripe to present: At least with the current ide, debugging
has evolved to a nightmare. That the debugger crashes for any minor reason,
like being pointed to a dynamic array (ANY dynamic array variable, not just
uninitialized ones), is a minor problem here. The real nuisance is the
handling of editor files. Assume you have a unit file open and try to
compile the program, but there is an error in the unit file. THis leads
unconditionally to another instance of the unit file to be opened to presnt
the error, AND if the unit has a form, complain that the form file CANNOT
be opened correctly, instead opening it as an ordinary text file AND
setting THIS as the active editor file. This is completely reproducible
here. And the same procedure happens even without an error on running a
program up to a breakpoint set with in an ipen editor file - it gets
RELOADED a second time, and the ide complains about an unability to also
load the uni's form as a form, instead presenting it as a text file. This
also happens, "of course", when a real error occurs during running a
program. It looks a bit like a problem with the editor's file management,
which cannot recognize whether a file is already open or hust blindly tries
to load any file or "unit" handed it by some other function, but alwayhttps://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 29 Mar 2024 23:31:28 +:

> By the way, there is a new release 5.10.2. with mainly fixes for msetimer

Got it, and works correctly, as far as I use(d) it - which means, works the
same as before for me.
And I proceeded at expanding the PSQLbrowser program, thereby adding the
capability to process fields of the postgres' types "interval" and ""money".
This required modifications to, of course, unit "mpconnection", but also an
addition to "msedb", which does the required formatting. It's probabely not
yet complete, as I haven't yet tested whether modifications of such fields
can work.
And I found a way around a road block I stumbled over in conjunction with
the database program. I DID want to keep separate filter and order settings
for all the tables accessed, but not have changes rewrite the status file
everytime for every minor adjustment. The memory stat file mechanism seemed
to be the right thing to use here, especially as I had used it - well, kind
of - with the "newdialogs" already. But, to no avail - although it was kind
of viable with the dialogs to preset what would be saved, this isn't
possible in the database case, as there's no predefined set of tables used.
Well, there IS a stat file entry written for the memory stat files, named
"savedmemoryfiles", but, as I had already found in the "newdialogs" case,
that is not persistent, any entry not refreshed durin a session gets lost.
It took me qute some time to find a work around this problem, and found
that this might even be an implementation error, as there IS a second user
function for additional modifications of status data, "onstateupdate". But
it runs (ran) in the same context as "onstatread" or "onbstatwrite", so
being not more than a slightly more complex version of these, essentially
useless. Sadly, the "savedmemoryfiles" entry gets deleted during loading
the memory file data just before "onstateread" and "onstateupdate" are
(were) called. This makes it impossible to set up the storage requests
adfterwards, as the value is gone. I had to rearrange the calling sequence
to "onstateupdate", reading the "savedmemoryfiles"' data and followed by
"onstatread" to be able to gain access to the pertinent data to keep the
memory files' contents and provide for their further perpetuation.
I even suspect that this was the intention for that whole mechanism, but it
wasn't finished, perhaps because it wasn't so urgently needed to have been
impairing. Using some simple manipulation of the data accessible that way,
I was able to keep an extensible list of selection data for any number of
database tables, and even could simplyfy the perpetuation of dialog
ancillary data quite a bit.
So I'm going now to provide an intermediate version of my modifications,
including the "newdialogs", though not complete yet, but working, and the
modifications to the database units created up to now soon. I'll give
notice when they will be available, as usual.
(BTW, I hope you don't mind my lengthy ramblings about my doing - I like
to think they could be useful as kind of documentation of what I did.)

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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 29 Mar 2024 23:31:28 +:

> Happy Easter holidays for you too!

Thank you, and to all mseide-msegui users, too.

> Thanks for your work, I am sure it will be perfect.

Certainly not - I don't command a big enough machine shop to be able to
ascertain everything...

> By the way, there is a new release 5.10.2. with mainly fixes for msetimer
> on Linux i386 and amd64.
> https://github.com/mse-org/mseide-msegui/releases/tag/5.10.2

Thank you for the information, I'll get it "immediately".
(I.e. I instructed my machine to fetch it on the next connection.)

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Mon, 12 Feb 2024 21:47:34 +:

Another Reply...

> There is a new release 5.10.0. with binaries of MSEide and the fixes of

After having downloaded the new version and synchronized it with my
modifications, the next step was to get the "reference" applications to
work with this version. Of course, apart from using the "newdialogs", they
DID work correctly.
This gave me the incetive for two other approaches:
- One, trying to get the "newdialogs" to fully work again. Sadly, I've not
succeeded yet. They MOSTLY work, even when shifted around, but positioning
is a nightmare - there are SEVERAL positioning methods and variables, and
not all of them seem to be always updated correctly. So I tried to set them
all, which mostly worked, except when a window straddles the top screen
border. I couldn't yet find any means to find the correct CLIENT window
position, as "decorated" and client positions are always returned equal, as
if there were no decoration at all. As that's clearly not necessarily
true, I'm stuck with that problem, although other positions are processed
correctly. I'll keep on trying...
- Secondly, I decided to tackle the "problem" of some missing database data
types for postgresql, namely the (date & time) "interval" and the "money"
type (which, I think, ought to be mapped to the existing "currency" type).
I DID succeed with that, or so it seems, as I've not tested that thoroughly
enough to be certain. But as I had to completely alter the existing, though
incomplete and unworkable, implementation, I'm a bit tired now and put
further verification aside some.
Therefore, I won't publish the modified units on my web site yet. But I
will pursue these topics and provide a working implementation when I see it
justified.

In the meantime, I want to wish you Happy Easter holidays,
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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release 5.10.0.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Mon, 12 Feb 2024 21:47:34 +:

> There is a new release 5.10.0. with binaries of MSEide and the fixes of
> inherited forms. Also compatible with Darwin-MacOs (via XQuartz).
> 
> https://github.com/mse-org/mseide-msegui/releases/tag/5.10.0

Thank you for your - as always - good work!
I'll try it out as soon as I can get it.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSEgui on the Mac!

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Thu, 18 Jan 2024 12:10:20 +:

> I hope all is ok for you.

Well, at least, I'm still ok, I think...

> I dont have a Mac, all was done via VMware, after decades I was finally
> able to install Mac OSX on a virtual machine. I have to agree that it
> works ok (few slow but ok).

Oh, indeed, at least for the intel Macs, this should be possible. And the
current OSX, AFAIK, is a (variant of) BSD-Unix, which you already got to
work for MSEGUI before.

...
> I have to jump deeper into the semaphores for the Mac that seem to be
> different than other Unix OS, it is the reason why virtual mseconsole is
> not yet working and running external programs, like fpc to compile the
> project.

Sorry for my ignorance - but does MSEIDE really use a virtual console to
compile? I thought it would use the common exec family functions of Unices,
which should be sufficient to pass it any data it requires and to receive
the output for display in the "Messages" window, so no terminal required?

> And so it is not yet possible to compile a msegui app using MSEide.
> To compile a app, the osx terminal is still needed (but it is not a big
> missing, you can create, edit msegui projects using MSEide and his
> form-editor on the Mac).

And you can get the resulting command line shown from the project/options
window to copy it into the console window, or even put it into a
smallish script file to execute. BTW, that's e.g. the method the "mc" file
manager uses to run its menu "scriptlets": copy it to a file in /tmp after
substituting all parameters, execute it by calling a shell, and then delete
it.

> But sure, when I get time, those semaphores will not resist and MSEide
> for the Mac will be compeletely fully working.

I'm certain you will succeed again.

> About XQuartz, it is more or less comparable to XWayland for Wayland.
> It is a layer that translate X11 methods to make it works on the Mac OSX
> graphic server. In the past it was installed by default on the Mac OS,
> but now you need to install it by your self. The great news is that
> XQuartz is still deeply maintained and compatible with each new version

I see. So as long a this is maintained, MSEGUI wil be usable on the Mac as
well. Somewhat similar to the equivalent problem with Wayland on Linux - a
somewhat shaky ground to build on...
On the other hand, there are a couple alternative interfaces, like e.g. GTK
(though the latest versions look "a bit" crude and blunt to me), or Qt.

...
> About your new dialogs project, keep cool, there is no hurry.

It _will_ take some time - the last thing I found out before putting it
aside was that the file dialog subwindows lost their connection to the main
window, appearing at unexpected positions when called up. I didn't find out
why this occures yet, but this has to be fixed urgently

> Happy and creative new year!

Thanks, the same to you, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSEgui on the Mac!

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Wed, 17 Jan 2024 00:59:56 +:

> A litle surprise for the new year: MSEgui goes on the Mac.

Fine achievement, congratulations for succeeding! Though I don't havea Mac,
and don't have any incentive to get one, this certainly is an opportunity
opening a wider field of use to MSEGUI, especially when - as I presume -
it also allows delevelopment on the Mac itself.

> It is done via XQuartz.

Well, as I said, I don't have one myself, and so I've no clue what  that
means...

But in any case, thanks for the achievement and all of your good work!

(Yes, and as you probabely, certainly have noticed, I didn't achieve
anything towards MSEGUI since mid of last year, as I got sidetracked by
quite a few things, though mostly private... Thus, my work on the
"newdialogs" was completely neglected all that time. and I hope to get
around to take care of it again "soon"...)

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] IDE

[Sieghard via mseide-msegui-talk]

Hello Fred,

in continuation to my previous "complaints" abour the functioning of
mseide's debugger function (last one from Tue, 3 Oct 2023 01:55:52 +0200),
here's some more information.

Main problem is: It's even worse than what I wrote before.
And there's obviously NO difference between the original mseide and ideU,
except that (AFAIR) ideU does not complain when a form file is loaded
multiply.
Apart from that, source (and the companion form) files are always loaded
when a breakpoint has been hit, even if the file was open even before.
Only when such a file was opened by the debugging processs itself it may
not be loaded multiply.
But sadly, there's even more: the same problem applies to compiling, i.e.
when the compiler hits an error in such a file, it will ALSO load it
another time, and, at least concerning mseide, will complain about an
already open form file.
Concerning the debugger dying, apart from uninitialized variables and
external constants, it also dislikes any instantiation of msestringarty
variables, and possibly all of the ...arty kind as well. I've not
investigated whether there's special code involved for handling the fpc
open array types, but if so, this is certainly not able to handle these
...arty types then, and so the debugger simply gives up, ending the
current session annoyingly prematurely.

Sorry for this bad news, that's what I just hit when trying to get the
msefiledialog working in conjunction with the "newdialogs" structure.
It's - mostly - working now, but I'd like to have it working also with
your extended "msefiledialogx", which shares a lot of code with the
original source. In fact, I already had set out to extract the common
parts and put them into a separate unit, but this was for an older,
outdated, version.
I'll notify you when I uploaded these units, hoping to find someone to
further test (and possibly refine) them and get feedback about remaining
errors and problems.

But in any case, keep up the good work and don't let you get discouraged!
Thank you very much!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] IDE

[Sieghard via mseide-msegui-talk]

Hello Fred,

now I can refine the conditions when the debugger dies some more:
it does that reproducibly when you hit an uninitialized variable with the
mouse pointer. (And it seems to see externally defined constants as
uninitialized as well.)

And, BTW, a question & suggestion: might it be advised to change the now
CONSTANT definition of a "StatExt" preset to an initialized variable, so
users can change it to another value (e.g. ".ini") if they want?

Apart from that, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] IDE

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Sun, 1 Oct 2023 20:12:27 +:

> I am busy to try your new dialogs.
> I try them for project ideU because it uses nearly all king of dialogs.

Don't hurry - DON'T, please!
The "newdialogs" STILL are work in progress, and as I wrote before, I've
not even yet tackled the "king of dialogs", "msefiledialog". I'm just
about "scratching my head" what to do to tame this queer beast.

> So I copied all the units of your newdialogs folder into the root
> directory of ideU project. I did not copy the customed dialog-units that
> uses variables shared with ideU.

Hmm - I don't quite get what the last sentence should tell...

> It is those units that are not copied:
> msestringenter.pas
> mseintegerenter.pas
> mseshortcutdialog.pas
> msefiledialogx.pas

Ah, I think I get it - you wanted to make sure your customized units are
used. This should be the case automatically when the ancillary units are
kept in a subordinate directory in the unit search path; that's how I did
it, and I didn't even notice that you had copies of the above mentioned
units in your source directory. Nonetheless, I got it to compile and run,
but indeed, I had to make a couple adjustments.

> But I get error at compilation:
> msedialog.pas(351,44) Error: (5000) Identifier not found "StatExt"

Upps, well, yes, that's a not-so-minor ommission on my part - I had added
a line "StatExt = ".sta';" in "kernel/msestatfile.pas", for use with the
extended "statfile" option "sfo_useexename", and possibly commented out
again - or, did I even upload the files, or just some patch information?

> And also now in ideU source:
> 
> projectoptionsform.pas(1717,30) Error: (5000) Identifier not found
> "colordialogstatname" --> Pointing to
> deletememorystatstream(colordialogstatname);  

Yes, this is s definition in the file "msecolordialog.pas" which was
completely unused throughout all of the mseide-msegui files, so I commented
it out. Indeed, I had to reenable it to compile your ideU, but I forgot to
mention - or neglected to do so, because I didn't expect you to immediately
try that out, too...

> I apologize if you have already given note about this but I did not find
> it in your previous mails.

No, I didn't, and I appreciate when you tell me about the problems you
encounter with your undertakings. That way, it should be easier and faster
to get it all working correctly. So, thank you for your information, and I
hope I could help you getting it all to run, as far as it has evolved.
(Mind you, remember, it is not finished yet, not before the file dialog
works!)

Success, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] IDE

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Sun, 1 Oct 2023 00:22:40 +:

> There are binaries of ideU here:
> https://github.com/fredvs/ideU/releases/

Yes, ok, I already took the source.

> You dont need to compile it to test the debugger.
> But of course if you want compile ideU with your new dialogs units, maybe
> it will be a few tricky because in ideU source there are also custom
> dialogs units.

I DID recompile it (version 2.12.0 now), and even threw my "newdialogs"
at it, and it compiled right away, and runs ok, on first glnce, at least.
Well, not so much ok, though, as it DOESN'T want to keep the font size
setting. Others too? It stupendously insists at always coming up with a
huge 17 point (?) default font, although I didn't attempt to change the
font yet. But that's a minor grievance only.
Amendment: I just found that _disabling_ the setting for the "Suggested
font height: 17" _does_ obey a saved font height. I suggest presetting
that as "unchecked".

Concerning the main pronlem I reported, the observations presented in my
last message do hold: if a unit file had been opened before, e.g. for
setting a breakpoint within there, the ide WILL reopen it a second time
when the breakpoint is triggered on a subsequent run. Your ideU just does
not complain about not being able to also open the form, at least when no
form was shown before.

Towards the stability of the debugger connection: I didn't test it a lot
yet, but very soon stumbled over a not formerly seen phenomenon. Trying to
have it show various variable values, I hit the name of an externally
defined constant string (the "StatExt" from "newdialogs/msedialog.pas").
And it died, reproducibly, after a short delay.
On the other hand, with the ideU, the debugger seems to be more stable
indeed. Although I did have a glitch where it died on a complicated
expression (FindText.dropDown.ValueList.asArray, to set the contents of a
history list), I could not reproduce it a second time, so this might have
been caused by something different I did.

So, so far the results look like this:
- Your ideU version 2.12.0 compiles correctly even with the "newdialogs".
- It IGNORES any previous font setting, if that's not explicitely disabled.
- It still places message windows (the "about" form, e.g.) at random
  spots sometimes, where they might be hard to see, especially below other
  windows. This might cause a situation where the ideU seems to hang.
- "Some" dialogs (it happened to me on the project save dialog) have bad
  formatting problems - an overly long line gets broken up to be rendered
  behind the dialog's buttons.
- The debugging code can die on certain conditions, like trying to access
  an externally defined constant.
- Otherwise, the debugging code seems to be more stable than that of the
  original ide, although this couldn't be thoroughly tested yet.

I hope that this might be of some use to you and help you to make your ideU
even better, although I probabely will stay with the original ide or just
my simple "make" script, because I simply don't need and thus not use most
of its features.

Thank you for your consideration, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] IDE

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 29 Sep 2023 21:30:45 +:

> like ping-pong call. But here it does not open new tabs of already opened
> units, it uses the already opened. And if a unit is not yet opened, it
> opens one it only once.
> 
> But maybe I did not understand your request, so please explain (I did try
> it with ideU, not yet with mseide)

That latter point may be the cause of your inability to reproduce the
problem - it may just not exist with ideU.
I usually use the original mseide for tracing and examining breakpoints,
or adjusting gui elements (which is not simple to perform outside the ide).
The reason I don't use your ideU is that I just don't have one compiled
all the time, as I used it a lot for testing some time ago and usually
remove the test remnants when no longer needed.
Otherwise, I usually compile a project from a terminal command line, using
the "make" script I already sent you (although slightly revised by now).
But I do need an ide for modifying or building a graphical layout, and
that's why I keep the original mseide available, never modified from the
distribution version. (I realize there is a utility to rebuild a _mfm.pas
file when the .mfm has changed, but I'm not sure whether this still works
correctly, and then I still had to integrate it into the "make" script.)


You wrote on Fri, 29 Sep 2023 20:27:52 +:

> Hello Sieghard.
> 
> > And if you need more information, please ask,  
> 
> Ha, ok, so here one: Did you try the debugger with ideU?

As I wrote above, no, not before. But now I tried. Well, and failed, at
first. A couple errors on compile - compilation didn't like to use my
"newdialogs", and dialogs weren't available, because I had put them aside
for my tests. After that, It didn't compile because of an incompatibility
with the "fontlist" unit. I had to add a "mclasses" to your "complang.pas"
file. But that may only have been neccessary because of the probabely old
version 2.8.4 I've still laying around.
And then, I tried to build a project with your ideU. The first time ever I
did that. Compilation failed again, because now it tried - of course - to
use the standard dialogs instead of the "newdialogs" used for the project.
Well, compatibility... that's still work in progress, after all. Just a
minor grieve. At the second attempt, compilation went through, and the
application - MSEclock - ran. I had prepared two breakpoints, one in the
main unit and another one in the modified "msedialog" unit, which was
therefore loaded in the editor  To test the breakpoint function, I then
activated the code triggering them, and they did show correctly. But the
ide did NOT just reuse the open unit file, as you wrote, instead it opened
it a second time, just not complained about something missing. Or did it?
Well... I can't say for sure, but when I then tried to continue the
application execution, the whole ide HUNG. No more activity, But after
some trying, I found a hint: the window manager window list showed an
entry hinting at a message to be dismissed, but nothing was to be seen on
the screen. Only after some moving windows between desktops, a window
saying "not decorated" showed up... This seems to have been the culprit,
but I can't tell you for sure anymore. I had left the arrangement on the
working desktop while I wrote this message, but just when I wanted to
continue and assert the "not decorated" message, there was a flurry of
window activity, and then - the whole arrangement was gone, the ideU just
showed a bland main window, and I cannot now tell you anything whether the
application would have continued to work or whatever else might have
happened...
But still, I have a suspicion what might trigger the multiple unit file
openings: could it be that this happens when the pertaining unit file has
been opened BEFORE starting the application, or perhaps even before
compiling it? Unfortunately, the accompanying mishaps didn't allow a clean
view of the course of events, so I will have to retry - later, though.

> I did change some code for launch-run the debugger.
> Maybe it is the way you like and I could some change in mseide too.

It will take me "a bit of time" to find out. But I will pursue the case,
and I will report what I can find. I hope that next time I will be more
successful.
Thank you for your consideration, and have nice weekend!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello mohamed,

you wrote on Fri, 29 Sep 2023 16:01:06 +:

> The remarks I sent are not emergencies but lines to be added to TODO list.

WHICH remarks? Whom did you send them? I didn't receive anything pertaining
to my projects from you.
Did you perhaps happen to respond erroneously to my message?

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] IDE

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Thu, 28 Sep 2023 18:04:31 +:

[ide "idiosyncrasy"]
> So yes it is a big bug and I need to jump into it (but not possible asap,
> sorry).

Well, there are a couple more I'm afraid... But anyway, don't overturn, do
your regular tasks first.

Then, you might be able to deal with the other stuff better, like e.g.
the inability of the degugging code to realize if a file containing a
breakpoint IS already open when it encounters it, opens it a second time
and then may complain that it cannot open the form file belonging to it -
very annoying.
The debugging code now is very delicate, it usually dies as soon as you
set the mouse cursor on a complex construct, probabely containing multiple
redirections, or it was with properties? I've managed to avoid that mostly
now. And there are a couple constructs that compile right away, don't
produce any kind of sign of an error, but simply don't work - I found that
to be the case mostly for the "window.decorated" values.
But, as stated above, don't hurry. The issues are mostly solved now, and
the problems can wait some, until there's time to tackle them.

Thank you for your good work, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Thu, 28 Sep 2023 00:46:40 +:

> How, you did a lot of work, thanks!

All things to amend insuffiencies I didn't want to perpetuate.

> I am hyper busy this week but sure I will jump into it this week-end.

Don't hurry, do your tasks thoroughly to make them last and not come back
on you.
Have good time, success!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

as it's by far finished yet, there is a new version of the "newdialogs"
units available now, along with the accompanying projects "MSEclock" and
now also "PSQLbrowse" for examples of usage. And I did include a short
description of the (IMHO) relevant features in the "newdialogs" zip file,
named "newdialogs.desc" (a simple ASCII text file).
Most dialogs should work as it is now, but there were a couple obstacles to
overcome, and there's still the hurdle of the filedialog to take.

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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

[MSEide-MSEgui-talk] New versions

[Sieghard via mseide-msegui-talk]

Hello Fred,

just for your information: the new versions of my newdialogs, along with
the MSEclock and PSQLbrowser, are now available from my mse web site.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSEgui and Wayland.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Sat, 23 Sep 2023 02:41:00 +:

> Yes, sure and I am far to be ready for a msegui-wayland interface.
> 
> I think that I have all the tools now to use Wayland with fpc, all the
> demos of the demos-book are translated and compile.

Fine - I saw that you presented a Wayland client window picture already.

> But the problem now is the C code from the book, compiling the C demos
> with some surface and shell does not run. It crash at loading.

Well - as I don't have any notion (yet) about what's required here, I'm
totally clueless in this respect - sorry.

> And it seems because of the shell used in the demo are not the one used
> by Ubuntu-wayland. So I have to adapt the code using xdg_shell that is
> used by Ubuntu. And I am a totally newbie in that jungle.

Strange - shells should be freely interchangeable I thought, even on a
graphical system, using a terminal program. Isn't that a terminal window
what your Wayland picture shows? I.e. is that just an empty window without
anything able to accept application requests?
(So, you need a "shell" to run a shell program? Funny...)
...
> Imho, Wayland is far to be ready and x11 has still long days before to
> disapear.

I sure hope so for Linux, and it's no question for the BSDs and similar
systems anyway, as Wayland, AFAIK, is narrowly targeted on Linux only, and
beyond that, on Linux running systemd. I don't run a systemd Linux...
(And I do not want to.)

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Sat, 16 Sep 2023 23:00:28 +:

[onmouseevent]
> Ha, ok, so I will add it in the "todo list of new properties" for next
> MSEide.

Alright. I've enabled it in my copy since the last version.

> >for the db code, I tested the PostgreSQL unit(s) using my "FieldError"  
...
> I did not test your last version, is it still on your web site?

No, sadly, there IS no latest version yet, since I didn't get along with
the PSQLbrowser test application yet, since I embarked on reworking my
"newdialogs".
This latter took me quite some time, since I couldn't find the reason why
some dialogs were "working perfectly" (or at least about as intended), but
others just wouldn't do what they apparently even DID - it just didn't show
up. The topic here is "automatically saving position [and perhaps other
data] for transiently created dialogs", menaing that it should not be
neccessary to keep their forms and data all the time an application runs.
The means to do this are "memory stat files", and they ARE able to perform
the task. But _some_ constructs - it seems, notably those using the dreaded
"controller" theme - use stat files in such an intricately convoluted
manner that it is nearly impossible to track their roamings and activities.
But by now, I've managed - albeit with some modifications to some existing
dialogs - to have them comply, except for those that use a controller
creating an unnamed and unowned internal form itself, leading to a clash
and a subsequent exception.

> But I fear that Med would be a much better tester than me for all about
> DB things.

If he wants to accept the task to do it on behalf of msegui deleopment
alone. Sure, it's helpful when someone does the testing of a new feature
using it in his application code, although really testing something needs a
lot more than that - many testing situations, on "all" supported systems,
and reporting problems, resolving them and re-testing again and again...

> >Well, yes, and that's a real challenge for a very small "team" of at
> >most a couple people as for mseide-msegui...  
> 
> Yes, I know, we are not many but we are brave. 

Well... How many are you? I'm afraid that would be the effective number of
testers and maintainers in the end...
You're doing a _really_ tough job, and you're doing it _really_ well.
And there should really be differnt people, with differnt opinions, working
together on that task, or should I write "mission"?

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Sat, 16 Sep 2023 13:25:00 +:

> >(It's  similar to the "onmouseevent" field of recent concern.)  
> 
> Hum, when I asked to commit that, you did answer that "I would not commit
> it...". So I did not commit it... 

Really? Here's again what you wrote and what I answered:
"
> So I did make public onmouseevent for mseSimpleWidget:
> In msewidgets.pas, added in parent class of simplewidget this:  
...
> And recompiled ideU with it.  

So it's useable with ideU only, not with the regular mseide?

> Now onmouseevent appear in object inspector for your panel-background.  

Fine.
"
Where or what do you read as me rejecting the new feature? I "interpret"
that as a neutral statement, "I don't care", so to speak. And I used it
according to your model for "MSEclock" to move the frameless window.

> Med proposed also to change source in msegui-DB, so maybe we could do a

For the db code, I tested the PostgreSQL unit(s) using my "FieldError"
"protection" function and didn't find a problem. The only problem that I'm
aware of was Med's exception using filtering, and that is resolved with my
latest version - although I'm not sure that it made it to you already,
because of current heavy and lasting communication breakdowns, with only
sporadic and limitied recoveries...
Yes, that's in Germany. The second biggest company.

...
> But before this, all should be deeply tested onLinux + Windows + BSD (and

Well, yes, and that's a real challenge for a very small "team" of at most a
couple people as for mseide-msegui...

> for Windows I dont have a Windows-machine to test at the moment).

That's even worse - as I wrote, I don't have a useable installation either.
And it should be a current Windows version to be reliable. And there's no
real "testing harness", or set of programs to check out for function,
stability and performance...
Any taker?

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Tue, 12 Sep 2023 22:09:41 +:

> >statfileoptionty = (sfo_memory,sfo_deletememorydata, //delete after read
>   >sfo_createpath,  
> //
> > sfo_useexename,  
> //
> 
> Yes, good idea!

Thank you.

> But if we add a element in statfileoptionty, mseide should be recompiled
> to see the option in the Object Inspector.

Certainly, and it had to be re-registered as well, I think. Like is done
for every new version of the mseide-msegui set (or mseide stand-alone
version) anyway? Or, for the full version, where the source is provided,
it's to be done by everyone themselves also.
On the other hand, it seems it wouldn't immediately corrupt the function
of an existing installation. The only drawback was that the new option
wasn't accessible without recompiling the ide, it could only introduced
"by hand", i.e. programmatically.
But, indeed, it's not a simple "drop-in" modification.
(It's  similar to the "onmouseevent" field of recent concern.)

(BTW, I'm still trying to implement a generally available statefile
mechanism for dialog storing positions. So far, it works only partially,
because of quite a few "intric(k)acies" of statefile handling as it is
done natively, and I don't want to modify this in any respect.)

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 8 Sep 2023 17:40:39 +:

[Re: The stat file mechanism]
And not to forget about the suggestion pertaining to the filename
parameter of a stat file, I still think it might be useful to have the
option to let the mechanism create the name according to the executable's
name, especially if that might be renamed:
It required the following modifications:

/// At the beginning of the unit file,
/// at the location give by the preceding snippet:

 statfileoptionty = (sfo_memory,sfo_deletememorydata, //delete after read
 sfo_createpath,
//
 sfo_useexename,
//

/// and

const
//
 ConfExt = '.sta';
//

/// And in the body of the procedure tstatfile.readstat:

 stream1:= stream;
/
// Suggestion: if no filename specified, use executable base name - ???
// - optionally do so only if a NEWLY DEFINED option ("sfo_useexename"
//   or so) is set
// - presumes fixed extension of "ConfExt = '.sta';" or such
// -code:
   IF (sfo_useexename in foptions) AND (NOT (sfo_memory in foptions)) AND
  (stream1 = nil) AND  // not a memory stat file ??
  (fFileName = '') // use program name as a "last ressort"
   THEN fFileName:= ExtractFilename (Argv [0])+ ConfExt;
/

This will set the filename to the "calling" name of the executable, i.e.
the name it was started with. This CAN be different on Unixen that know
soft links, since this will be the soft link name, not the name of the thus
referenced file itself. (As hard links cannot be recognized, these will
always result in a stat file name of the real executable name.)

If you this might be of use, you can include it in the library unit.
I can provide additional information if you require.

Thak you for your consideration, success!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 8 Sep 2023 17:40:39 +:

[Re: The stat file mechanism]
So here is another follow up message, this time pertaining to the
previously presented amendment to the stat file mecahnism, unit file
"kernel/statfile.pas".
I was a bit overly eager to get this working for writing a stat file, when
no path formerly existed. This does indeed work with the listing of the
"tstatfile.writestat" routine I had included.
BUT - of course, after it was created successfully, the stat file ought to
be successfully reopened and evaluated on a succeeding invocation of the
program - and that's a point where most of the same measures as for writing
had to take effect. So another, equivalent, modification has to included.
So, to avoid too much code duplication, I put the required statements in a
separate procedure that is called in the "writestat" and as well in the
"readstat" method at the appropriate place. Using this, it's possible to
simply use the common "~" HOME designator on Linux and the bsds (if that
can be used there at all, if not the conditional had to be adapted) and to
specify a path without a trailing separator character, as otherwise the
path gets directly merged with the file name, leading to some unwieldy
nameing "effects".
I just provide the "diff" output here, performing a (probabely inverted)
patch should produce the modified version of the unit file for testing:


107,109d106
< /
 DirectorySeparator

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 8 Sep 2023 22:42:59 +:

> >WHAT "green light"?  
> 
> Did you try mseclock and all the "newdialogs" already on Windows too ?  

No, because of the lack of a really working, even current, Windows. The
latest I have available (but not registered, let alone being "activated")
is an olden Windows 7, and I'm not even sure whether it is 64 bit capable
(probabely not). So no, I didn't try on Windows because I can't.

> I prefer not to hurt you if I find something to change, so I let you with
> the commands.

No problem - I'd even welcome if you found something to be fixed (and
perhaps a resolution for it as well), and, of course, you're free to
include it in your effort. Sure, for a release, testing on every platform
the software is intended for is a must. But as stated above, I could at
most test it for the arm line of Linux, when I get that to work - for now,
I couldn't get any msegui application even to compile because of a weird
linking error, where the linker reports it couldn't find some start up
object file that in fact does exist.

And after all, as long as there are no system dependent functions involved
(as is most probabely the case with the "newdialogs", and the "MSEclock"
application except the "experimental" screen copy test routines), there's
no reason why something should fail, if not because of a problem in the
underlying (library) code. Isn't that the boasted claim of fpc anyway?
And Lazarus adopts that directly, doesn't msegui?

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 8 Sep 2023 17:40:39 +:

[Re: The stat file mechanism]
I did some playing around with this to explore the actions and effects
provoked by specifying "unusual" parameters, specifically for the "filedir"
and "filename" parameters.
Doing so, I realized that the "filedir" parameter isn't merely a single
directory specification, but an array of such, akin to the "PATH"
environment variable. Unfortunately, this can provoke some unexpected
effects, especially in conjunction with Linux' (Unix') "HOME" directory
designator, '~'. Thus, I inserted a preprocessing step to the "path"
handling that replaces a leading '~' character with the HOME directory
specification. This also works if just a single directory is given there.
And I also made provision to the case that a directory specification does
NOT end in a slash by adding one in that case.
I append the resulting code to this message directly, because the
modification is rather localized and does only pertain to the procedure
named "tstatfile.writestat".
As another point, I ALSO included a suggestion for a minor extension of
this procedure, to allow for an empty filename to effect the use of the
(base) name of the executable program, rather than to silently ignore the
stat write request, as it does now. This is just a suggestion, and might
be considered unneccessary, or it might be made optional by extending the
set of option values by something like "sfo_useexename".

This is the modified procedure:

procedure tstatfile.writestat(const stream: ttextstream = nil);
var
 stream1: ttextstream;
 ar1: filenamearty;
// fname1: filenamety;
/
 i: integer;
/
 bo1: boolean;
begin
 if assigned(fonstatbeforewrite) then begin
  fonstatbeforewrite(self);
 end;
 if fnext <> nil then begin
  fnext.writestat(nil);
 end;
 stream1:= stream;
/
// Suggestion: if no filename specified, use executable base name - ???
// - optionally do so only if a NEWLY DEFINED option ("sfo_useexename"
//   or so) is set
// - presumes fixed extension of "ConfExt = '.sta';" or such
// -code:
//   IF (stream1 = nil) AND  // not a memory stat file ??
//  (fFileName = '') // use program name as a "last ressort"
//   THEN fFileName:= ExtractFilename (Argv [0])+ ConfExt;
/
 if (stream1 = nil) and (filename <> '') then begin
  if sfo_memory in foptions then begin
   stream1:= memorystatstreams.open(ffilename,fm_create);
  end
  else begin
   if floadedfile = '' then begin
unquotefilename(ffiledir,ar1);
/
FOR i:= 0 TO high (ar1) DO BEGIN
{$IFDEF linux OR defined (freebsd) or defined (netbsd) OR defined openbsd()
  OR defined (Solaris)}  // Or whatever is needed here...
  // On Linux, resolve tilde character and replace with home directory
  IF ar1 [i][1] = '~'
THEN ar1 [i]:= GetEnvironmentVariable ('HOME')+
   Copy (ar1 [i], 2, Length (ar1 [i]));
{$ENDIF}
  // No directory separator after directory name?
  IF ar1 [i][Length (ar1 [i])] <> DirectorySeparator
THEN ar1 [i]:= ar1 [i]+ DirectorySeparator;
END;
/
if not findfile(ffilename,ar1,floadedfile) then begin
 floadedfile:= defaultfile(ar1);
end;
if (sfo_createpath in foptions) and not findfile(floadedfile) then begin
 createdirpath(msefileutils.filedir(floadedfile));
end;
   end;
   try
if sfo_transaction in foptions then begin
 stream1:= ttextstream.createtransaction(floadedfile);
end
else begin
 stream1:= ttextstream.Create(floadedfile,fm_create);
end;
   except
floadedfile:= '';
raise;
   end;
  end;
//  stream1.encoding:= fencoding;
 end;
 if stream1 = nil then begin
  exit;
 end;
 try
  if (fcryptohandler <> nil) then begin
   stream1.cryptohandler:= fcryptohandler;
  end;
  awriter:= tstatwriter.create(stream1,fencoding);
  updateoptions(awriter);
  bo1:= false;
  try
   if (stream1.handle <> invalidfilehandle) and
   not stream1.usewritebuffer then begin
bo1:= true;
stream1.usewritebuffer:= true;
   end;
   internalwritestat;
//   if assigned(fonstatafterwrite) then begin
//fonstatafterwrite(self);
//   end;
  finally
   freeandnil(awriter);
   if bo1 then begin
stream1.usewritebuffer:= false;
   end;
  end;
 finally
  if stream = nil then begin
   stream1.Free;
  end
  else begin
   if (fcryptohandler <> nil) then begin
stream1.cryptohandler:= nil;
   end;
  end;
 end;
 if assigned(fonstatafterwrite) then begin
  fonstatafterwrite(self);
 end;
end;


Thank you for your consideration, and keep up the good work!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, 

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

this is a follow-up to my message on Wed, 6 Sep 2023 00:24:37 +0200.

Although it's unfortunate that you didn't have the directory and stat file
for storage of MSEclock's settings, this might not neccessarily have lead
to an error. The stat file mechanism DOES already have an option
(sfo_createpath) to silently create both path and file when set - the
reason it didn't is simply that I was unaware of that option and so it
was left unset. Perhaps the option should be set by default for non-memory
resident stat files?

If the option had been set and everything else were right, MSEclock would
not have shown an error message and simply created the state file silently.
But not everything IS right in the line of actions running for that
purpose. I did some investigation on behalf of introducing an automatic
file - and directory - creation function as you requested (which turned
out not to be required anyway), and found a blatant error in a quite
deeply entrenched unit for file and stream operations. So, even with the
before mentioned option set, the creation of a stat file would have failed,
failed silently, and thus probabely given the impression that the state
mechanism didn't work...

The cause is located in unit "msesysintf", function "sys_openfile". This
should open a file of a given name and return an error code and a file
handle. Well. It does, but - when the file does NOT exist, it returns
"sye_ok", the success code, and an INVALID file handle of -1. But there's
NO check of the validity of the file handle returned after this call, and
so the processing happily calls a number of file access functions that all
fail, without even noticing it. But that doesn't matter, as after that it
sets an internal variable saying that it HAD successfully loaded a settings
file, although in fact nothing at all of that has happened.
The real problem only arises on write back time - then, the writer routine
checks this internal variable to see whether an input file had been
successfully processed, and uses that to write back the new settings.
Well, and, of course, it ALSO FAILS miserably, because there IS NO FILE.
And it doesn't even notice it again, because it runs into the same error
as the reader routine again, where the system function reports that all
was right when in fact it was unable to do anything at all.
The resolution to that failure is not even difficult, a few lines for
testing the handle returned for validity and setting the error result
accordingly do what's needed, and this is accomplished by adding the
following lines to the end of unit file "kernel/linux/msesysintf.pas",
starting at line 710:

/
  IF handle < 0 THEN BEGIN   // AN ERROR HAS OCCURRED!
if openmode = fm_create
then result:= sye_write
else result:= sye_read;
  END
  ELSE BEGIN
//---
 fpfstat(handle,stat1);
 setcloexec(handle);
 result:= sye_ok;
//---
  END;
/

The lines between the two "//-" lines are already in place, and that
was the only exit path before, thus never reporting an error condition...
There are some minor points of failure in the code following that call,
but they apparently don't do any harm as they just don't do anything at
all, so I left everything other as is, tested the modification, and found
that IT WORKS!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Wed, 6 Sep 2023 23:53:13 +:

> >> used for tfiledialog". To register the "tfontdialog" component as  
> 
> > No, why should that be neccessary?  
> 
> I was talking about a widget that can be edited by the GUI Object
> Inspector.

You could create something like a "calling shell" that can be parametrized
with the "personalization" data, and retrieves the results. But that's
certainly not a "controller" of that kind. The dialog itself is a
self-contained subform.

> But I agree with you, it is not really needed for the fontdialog, it is

I'd even question the need for a few other dialogs, particularly the _file_
dialog. Perhaps the plan was to have an input-edit-like widget for quick
file specifications - did you ever use or want to use such a thing? Yes,
there are some uses for something like that, but just "firing up" a full
fledged file dialog and processing its eventual result isn't much more
effort, and most applications I know even just use the system file manger
as such a "dialog". Even Windows does.
Other examples for such things are the color dialog, the popup calendar or
the memo dialog. Only the family of drop-down components has a valid use
for the controller concept, IMHO.

> more needed for visual component like pannels, stringedit, etc...

A string edit doesn't need a controller - it's a component for building a
dialog, and maybe a "controller". This also applies to all the -enter
"dialogs", they're mere components for building dialogs.
And, BTW, if you look at the "dialog" section of the component palette, the
only _real_ dialog found there ist the file dialog. All the rest are mere -
but nonetheless neccessary - building blocks for dialog forms.
BTW, the color dialog doesn't even appear on the component palette.

> So ok, sorry for the noise.

No, THIS kind of noise is neccessary - this is a quite basic issue, and
has to be discussed thoroughly to be resolved right. After all, I may be
wrong with my opinion as I'm just judging from my needs and preferences.
Others might have a quite different view of this issue, and might want it
handled differently. This should be discussed and decided unanimously.

Thank you for all your effort and cooperation, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Thu, 7 Sep 2023 00:00:21 +:

> > But I want to suggest to make that a  
> library standard, implemented in some part of the "statfile" mechanism.
> What do you think?
> 
> Yes, the statfile mechanism is problematic sometime.

In principle, it's kept "ASAP", meaning "As Simple As Possible" here. It
does NOT restrict anything not directly required, leaving the most freedom
to the user / programmer possible.
But in practice, _beeing able_ to delegate the lower task of file (and
directory) handling to some built in, standard mechanism, can make it a lot
easier for the casual user, as the only thing he must care about is perhaps
setting an option flag.

> For example. in NetBSD the "~" like in   "~/.config" is not recognized as
> "root directory of user" but as a normal character.

That's not neccessarily a problem - Windows will not recognize that either,
and so it should, if at all, be handled by the library unit internally
anyway.
(Sadly, as I don't have much information about Windows' internals, I do not
have reliable information about where Windows wants applications to store
their state data and how to get knowledge of this. This would have to be
added by someone who does, as a compiler conditional probabely.)

> And using the /etc directory is not optimal too because it needs root
> access.

Yes, as is using the executable directory on Windows...  Although THAT
will silently relocate the stat file to a place no one suspects. AFAIK.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Wed, 6 Sep 2023 13:31:22 +:

> Indeed, when creating "~/.msetools" , no more errors.
> But, humm, what do you think about:
> -First check if the directory exists, if no create it.

I didn't care because that was introduced, after quite some discussion, a
long time ago by Martin himself.

> -Or why not use the "~/.config"  directory that is provided (normally) in
> each Linux distro?

This was discussed as well, and dismissed, because that is not neccessarily
reliably available. It's more a GUI dependent facility, used by gtk and
gnome or such. I do realize that it's quite common nowadays, but wasn't
even when this was discussed. And, BTW, there's the IDE settings directory,
~/.mseide, which "always existed", on the same level. So, as of this olden
lore, I didn't even suspect that the directory might not exist if any
msegui application was run on this machine before...

> ( I am ok to use "~/.msetools" but then check first if it exists, if no,

Well, after all, this IS a valid point I just overlooked (as explained
above). It might even be sensible to just create it if it not there, as the
home directory is _meant_ to be a "dumping" area for this kind of (private)
data (just like "/etc" is for system wide settings).
I shall include it in my applications. But I want to suggest to make that a
library standard, implemented in some part of the "statfile" mechanism.
What do you think?


you wrote on Wed, 6 Sep 2023 13:53:26 +:

> Sorry if 3x same mail but 2 previous do not appear, maybe too big because
> of included previous mails.

Well, I got it just twice.

> New try without previous mai includedl:

That's nice, reducing the littering of your correspondent's mail archives
quite a bit, and also limiting band width and energy consumption, although
just a tiny bit, especially compared to all that sense- and useless spam
trash.
PLEASE continue your correspondence in this same manner!

Thank you a lot.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Wed, 6 Sep 2023 14:30:58 +:

> > Be warned - it uses the special dialog form from my "newdialogs".  
> 
> Yes, of course I used it  !

Ok, then everything should work now.

> Now there is a other challenge, makes your msefontdialog a widget for
> mseide.

> For this it needs to create a tfondialog class with a "controler" like
> used for tfiledialog". To register the "tfontdialog" component as

No, why should that be neccessary? I don't even see a need for the
"controller" in the file dialog, that, in my opinion, just serves to (over)
complicate the thing, and quite some others, too. Probabely Martin meant to
consolidate many dialog functions using such a construct, but to me, it
looks a lot like he went off track with that.

> But for the controler, for the test it was only a dummy controler.
> And to do a working controler it is a other story, but sure you will do

Only if you show me a compelling reason to do so. As it is, the dialog does
what it was designed for, and it has more features than any of the standard
dialogs of mseide. Specifically, it is fully relocatable and placeable. Try
that with any of the original dialogs. There, the "controller" is just
needed because they are nailed down to their design parameters, to break up
this fixture and allow for some external control through the back door, so
to speak. I dislike such snaky proceeding. With all due respect for
Martin's huge and impressive work, one must still see that this was - is -
the work of a single person. Which impies that it WILL have its
limitations, even flaws and detours. I DO consider the original dialogs to
be mostly examples of such. (Mind you, not ALL of them do have their own
"controller"! And there ARE objects incorporating useful controllers, too.)

Bur anyway, don't mind, have a good time and success!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello vasi,

you wrote on Wed, 6 Sep 2023 13:29:49 +0300:

> https://www.bu.edu/csmet/files/2021/03/Getting-Started-with-SQLite.pdf
> https://www.pearsonhighered.com/assets/samplechapter/0/6/7/2/067232685X.pdf
> https://kshmirko.github.io/static/sqlite_tutorial.pdf

Thank you for the links, that will save me quite some time researching for
the literature.
(As the weather here is very sunny and fair right now, there's a lot of
work to do outside, and then, there's something unpleasant lurking in the
back, too: the yearly tax declaration...)

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Mon, 4 Sep 2023 21:50:21 +:

> For the language selector I get a "Stream write error" message when
> clicking on OK or Cancel.

Oh, and another question, as that - probabely - will be the cause of the
error message: DO you have a directory "~/.msetools" for msegui
applications to store their settings, or are you working under Windows
(where I don't know now where settings are stored commonly)?
NOT having one did provoke the error when I checked. (Any other setting
change should do the same, probabely, then.)

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Mon, 4 Sep 2023 21:50:21 +:

> Indeed, with all his units in mseclock project, it compiles now. ;-)

Fine.

> I like your msefontdialog, very usefull and of course it will be part of
> msegui widgetset.

Be warned - it uses the special dialog form from my "newdialogs".

> For the language selector I get a "Stream write error" message when
> clicking on OK or Cancel.

Interesting. But that doesn't occur here, although some problem might have
crept in because I didn't test it since last time I worked on it. And I
don't even see a place where a stream write might occur there, although it
does use (load) the "msestream" unit. (I even tested with ANY language file
access removed. Only english remains then, but the language dialog does
work without an error. For me, that is, having compiled with fpc 3.2.2.
and msegui 5.8.6.)

> For all the other dialog widgets, I did not catch yet the difference with
> original msegui-code. (but I did not yet jump into your code to see the
> diffs).

As I stated, the "catch" is that all dialogs using a sparate form window
can be freely located, the form manipulated (e.g. set to another font,
color scheme, even a full separate skin [probabely, not tested]) and this
information can be retrieved in the application and saved for later use.
(As a further enhancement, I thought about making storage of these data an
internal property of the dialog, but there are some issues when the dialog
form is only transient.)

> For your other database project, I will try it asap.

Be warned, it REQUIRES PostgreSQL, as that is the database system I (and
my tax calculation ["ERP"] system) use. I've not found a good manual for
sqlite yet, and although I do have a mysql manual, I don't have the
software... Oh yes, and even though I do have an ODBC - hm, what's the
right term for that? - "driver" installed, I wasn't able yet to correctly
set this up for access to anything. Perhaps that might be the best
candidate for the next version, as this promises to allow access to nearly
any (SQL) database system. But at first, I have to get it working.

> Many thanks.

I hope you can enjoy it anyway, or at least get it all to work correctly.
So, I wish you success, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Mon, 4 Sep 2023 14:14:04 +:

> > I DID state that this version ALSO uses my previously presented
> > "newdialogs".  
> 
> No, I dont have those previous version, like I already explained, I have
> a new computer without saved-backup.

Ok, that's a valid reason. I uploaded the current version now anyway, since
I moved the "msefontdialog" files there. For one, they do rely on the units
there, and to slightly enhance the (minor?) chance they might get included
in msegui's stock, maybe as alternative to the standard dialogs?

> Please, Bitte, por favor, if you dont use the "official" last release of
> MSEgui https://github.com/mse-org/mseide-msegui/releases
> or some modified units, copy those modified units in the root directory
> of your project.

Well, as you asked quite some time ago whether to include this minor
modification AND AFAIR noone opponed, I thought this was already accepted,
Yes, and then I simply forgot that I had to do the modification myself once
again... Sorry for this.

Anyway, in conjunction with the "newdialogs", I uploaded the latest project
data again, because there were a couple of modifications and corrections.
And, after all, I MUST mention that BOTH are still WORK IN PROGRESS, i.e.
they ARE NOT FINISHED YET. Even the "newdialogs" aren't, as I plan to
extend the dialog forms to allow fpr automatic status storage by means of
Martin's "statefile" mechanism.

Once more, I'm sorry for the nuisance.

There's just the problem for me that I try to produce something useful and
create enhancements for msegui, but don't get much, if any, feedback. And
that's the reason why I didn't work at and with msegui for quite some time
now - the "MSEclock" application is of no use for me other than to suggest
some extensions to the dialog stock. And this seems to have failed.
Then, the recent questions about database functions prompted me to embark
on a new project I was thinking about some time already, using msegui as
its base. And that's the "PSQLbrowse" application, which in turn led to a
couple enhancements of other things, resulting in the current uploaded
files. I do recognize that it's not the best way doing that via a private
web site, but in my opinion, that's a lot better than as attachements to
mailing list messages. (But, if you wish, I could make the site reachable
via my "home" site also. It probabely won't hurt or effect much traffic
from "third party" people being interested.)

Anyway, I wish you all the best, 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
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Sun, 3 Sep 2023 01:17:44 +:

> I try to compile your new release of MSEClock but there are some errors:
> 
> Compiling ./MSEclock.pas
> ...
> clockwork.pas(288,7) Error: identifier idents no member "onmouseevent"

Yes. This is due to an addition you had suggested a couple subversions ago
and not yet instituted: at line 985 in file "msewidgets.pas"

   // property onmouseevent;  // should we not enable it ?

I did.

> clockwork.pas(365,9) Error: Identifier not found "execute"
> clockwork.pas(375,60) Error: Incompatible type for arg no. 1: Got
> "tcolordialogfo", expected "tdialogform" clockwork.pas(376,20) Error:

I DID state that this version ALSO uses my previously presented
"newdialogs". Don't you have them anymore? Then I should upload them anew.
There's a completely new dialog included for font selection akin to the
kind most applications under X do provide now. It was already there with
the previous version of MSEclock (that also requred the "newdialogs"), but
is now extended to (as far as I can see) full control of font properties.
And I DO suggest the "newdialogs" for consideration for inclusion into
msegui, if "only" because I hate dialogs that are nailed on an arbitrary
position on the screen. All of your errors except the first one DO arise
from this omission. Should I upload the "newdialogs" directory another
time?
BTW, there's another new dialog, "replacedialogform.pas" (which is really a
search or replace dialog), that doesn't have a corresponding implementation
among msegui's dialogs. It's included for your examination and for possible
inclusion (probabely renamed) into msegui's stock of dialogs.

And, in addition, in the meantime I found a - clunky-clumsy - work-around
for the posting problem in the database browser application.
And I renamed it, because "PSQLcat" doesn't seem a fitting name after all.
It's called "PSQLbrowse" now, and all its functions seem to work correctly,
as far as I was able to test them.
Be warned though: this does ALSO usee my "newdialogs"!

BTW, in conjunction with my playing around with this application, I found
a problem, if not omission or even error, in the msegui database functions.
The issue is that closing a database does NOT correctly, i.e. completely,
de-initialize the datasource. Specifically, it does not discard the field
data structure built-up for the formerly open database, and on opening
another one that has a different field structure it fails, trying to access
the old fields again.
This is a basic problem, as it originates from the "mdb.pas" unit in the
"fpccompatibility" directory. I did not try to tinker with that, but
includedd an explicit de-initialization statment, "SQLquery.Fields.Clear;"
in my application, although I believe that it does by no means belong
there. It took my quite some time to figure out why opening a different
table did always fail after any modification of a value in a previously
opened table. Although this will not hamper an application only dealing
with only one table per data source, it DID bite me for accessing different
tables using just one over again.
Well, problem solved - but should that be kept so, or was this a candidate
for an amendment of the library function?

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Mailing list & mseide-db woes

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Sat, 2 Sep 2023 04:28:03 +:

> Sorry but I did not note those new versions of MSEclock, PostgresSQL and
> mailing list

So indded some of my earlier messages semm to not have made it to the list.
Well, after all, this former one obviously did, at last.

> I just went to your site and indeed there are new update for 2023.
> I will transfert it to mseuniverse demo.

You should have checked it first - it uses my "newdialogs" (for
placeability), and includes a slightly extended "msefontdialog" as its
main feature.

> But, appart to me, did you give the address of your site ?

You DO have it, otherwise you wouldn't have been able to access it, don't
you? Would you prefer if I made it accessible from my main site?

> I think you prefer not to make your site "public" so is difficult to
> follow your updates.

That's why I always write a message to the list after a change. Sadly,
this time these messages don't seem to have gotten through, and that's
why I asked again.

> I understand that you dont want to be a Github user but it would be much
> easir for everybody if you share your demo there.

That's not a problem - you're free to include it there, where and how ever
you deem it fitting.

> About your new demo of PostgresSQL, I have to install all the dependence
> for database server, I hope it will be more out-of-the-box than FireBird.

Don't hurry - it's by no means finished yet, just barely working by now.
And I did use PostgreSQL mainly bcause that's the database system a quite
important (tax) application I use requires, prompting me to use it for
several other things as well.
Getting it installed shouldn't be too difficult, and setting up a database
should be easy as well. But getting it to know and use in full is a
different thing. There are a number of - mostly trivial - tutorials, but
there's also a very complete manual available from its developers. It
originanted at the University of California, Berkeley, Computer Science
Department , where you can find some
stuff about it.
Sadly, I don't remenber where I got my (.pdf) manual from, maybe it was
from the development site,  directly.


you wrote on Sat, 2 Sep 2023 04:56:32 +:

> About your problem with floating point formats, I need to jump into
> database-postgress, I will do asap.

As stated above, don't hurry. I mentioned that only, in case someone else
might already have noticed the problem, taken care of it and perhaps even
found a reliable solution, or work-around. It's probabely not even really
relevant for a specific application that uses fields of well known data
types, but as I wanted to write a "universal" browser, I have to find a
way to get it going without such prior knowledge.

> But it seems that the project mOMot2. that uses fpc, is very complete and
> they have some "workaround" for missing fpc things. When I am a few more

Thank you for the information, I will certainly study it. Just have to get
its data first.

> Of course, I would be good too to ask it to fpc forum (but I dont have

Yes, this seems to arise from a limitation of fpc, probabely caused by the
development and diversification of PostgreSQL - they might have implemented
just the neccessary support to make it going mostly, while their focus
probabely was more at mysql / mariadb.
But, as I also wrote, I'm planning to try to port it to sqlite too,
although that's quite different in its basics, i.e. "database" definition
and management.
And, after all, don't hurry, you got suffient other work to do. And I / we
definitely don't want you to go Martin's way off the project...

Have a nice time, and stay well and healthy!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] dropdownedit tdropdownlisteditlb

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Sun, 27 Aug 2023 20:50:18 +:

> >I think "nabble.com" might still be active.  
> 
> No, they deleted the mseide-mesgui nable site (without warnings).

That's definitly not nice. The only excuse could be, they had tried to
inform the list owner (i.e. Martin) and got no response or even a reject.
Sorry, short from running one oneself, I don't know another carrier.
Just maybe, you could try the converter server I use for reading the list
like a news group, gmane (news.gmane.io). _Maybe_ they also provide a
mailing list service.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] dropdownedit tdropdownlisteditlb

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Sun, 27 Aug 2023 18:15:24 +:

> But it seems to me that using github for the attachments via
> issues/discussions is a easy way. Of course via the mailing list would be
> better but sourceforge dont want anymore...

There are still some other mailing list servers around. I'm not sure, but
I think "nabble.com" might still be active. But the internet seems to go
the "consolidate" route - it's drying out, just leaving the web protocols
(http, https) for commercial use, and nothing for private persons anymore.
Yes, EMail _might_ prevail some more, but beyond?

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] dropdownedit tdropdownlisteditlb

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 25 Aug 2023 19:08:26 +:

> Of course your samples are more than welcome.

Ok, I'll prepare some samples if you care to state a format.

> AsI have already warned, msegui DB is new jungle territory for me.

Well, I think that's the right characterization... Not that the functions
are extraordinarily sophisticated, but they are quite convoluted, and the
documentation is "not quite up to msegui standards", so to say. I think you
can derive what that should mean.

> The last time I worked with DB, it was with Clipper (a pseudo-compiler
> for DB3) and all seems to have a few changed since that heroic days... 

Clipper? That must have been more than 30 years ago! Clipper was a dBase
dialect, AFAIR. There were a couple "dBase compilers" other than that, and
I even had done a project or two with one. I even had written a dBase
display program with Turbo Pascal (the source of which I still have).
But these days, you will HAVE to learn SQL, the "Structured Query Language"
for databases. It's quite well standardized, but "a bit quirky" as seen
from the point of view of a real programming language user. SQL is NOT a
full programming language, but most database systems these days use it for
data entry and retrieval, so one cannot ignore it if one has to work with
them.
On Linux, there are mainly 3 database systems in common use:
- mysql, or now, as this was incorporated by a commercial "development
  company", its follow-up version "mariadb". AFAIK that's free for private
  use, and is often the system of choice for web server use.
- postgresql, a rather professional, but still freely usable system, that's
  less commonly used on Linux, although some more commercial applications
  use it, like e.g. the "GnuCash" tax calculation and ERP financial system

Both of these are client-server systems, i.e. the data management is done
by a server deamon process that handles the real data storage and
retrieval, and client applications that connect to it to provide or request
the data of interest. Both of them can also work over a network connection.
And then there is the third system, featuring a "slightly" different
approach:

- sqlite, a stand-alone database system, somewhat similar to dBase or
  Clipper, that is meant to be integrated (compiled) into the application
  using it. Its databases are stored in separate files along with tha
  application data, usually with an extension of ".sqlite". You probabely
  know these from firefox or thunderbird or a couple other similar software.

On Windows, there's, of course, the MS "native" database system (I cannot
remeber the name of) and (I think) the former "Interbase", AFAIK now called
"firebird", from former Borland Inc.
And then, there's an approach at integrating everything being able to
"speak" SQL by an integrating layer for data provisioning called "ODBC",
the "Open Data Base C". It is so
universally capable that there's hardly an operating system without an
implementation or a database system for which no driver is available
(although NOT all of them are free).
Our msegui also has an interface for that!
I'm using postgresql for the application I use for my financial activities
and a couple data collection functions, and, of course, though only
indirectly, sqlite by means of firefox, mostly.
I' planning to put the aforementioned database "browser" (for postgresql)
on my web site shortly (in conjunction with a couple other things), but I
will give notice here.

> @Med, for the name of fields, maybe check the datasource used by the
> dropdownedit. (I have to jump into msegui-db, I dont know)

Could it be that this application does direct accesses to the sqlquery
result data provided by a query? The "canonical" way seems to be meant to
use the query only indirectly through the "datasource" module, but this
might not be done consistently. Just a (wild) guess...

See you later, and wish you very well in the meantime!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] dropdownedit tdropdownlisteditlb

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 25 Aug 2023 13:50:19 +:

> Imho, it would be much better if the data-test used would be something
> more understandable-real-life than 'hdskdkjdlkds' or 'qhhsusuidddcas'.

Indeed.

> (And of course it would need to create those data and yes, it is boring
> work)

That's THE problem - whoever would want to do such things?
But - if you took the trouble to provide a _specification_ of data you
wanted to use in your demos, maybe that could be done by some code?

BTW, if you think of time series of more or less random data, I _could_
perhaps provide some "interesting" samples. Could a section from energy
collection values from a PV system do? Or voltage recordings from a battery
test stand? Or simply "arbitrary" consumption values from some arbitrary
facility? Of course, these are all time series, including integer and real
values, randomly some strings and other data formats. You had to specify
the transfer format (SQL, csv, xlsx?) and expected size. The selection will
be done in such a manner as to allow usage for time series graphing, but
nothing as to what they mean or apply to will be accessible.

As I wrote, I DID embark on a new "project", a more or less universal data
base browser for (my) posgresql data, and it's even mostly done. Due to
some quirks of, probabely, fpc itself it cannot access all data yet, as the
data base routines don't know about some postgresql data types. These are,
as far as I found, enumeration types and time intervals. They are simply
returned as "ftUnknown" without any data, and there seems to be no way to
access them or get more information about them. That's blocking my way now.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Run msegui apps on NetBSD and OpenBSD freeze if using 2xclick.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Tue, 15 Aug 2023 01:39:42 +:

> Yp, I get it.
> 
> In mseapplication.pas,
> constructor tcustomapplication.create(aowner: tcomponent);
> 
> At the end, line 1248 there is a "lock" and, strangely for NetBSD and
> OpenBSD it blocks the application when 2x click on the binary from a
> window manager.
> 
> This fix it:
> 
>  {$if not defined(openbsd) and not defined(netbsd)}
>  lock;
>  {$endif}
> 
> Tested deeply on both openbsd and netbsd, all is working perfectly, even

So this nullifies my suspicion about a possibly missingcontrolling terminal.

But - did you also test it with threaded applications (e.g. the ide)?
As I see it, this "lock" uses a system mutex data structure which is used
for thread interlocking and such things to avoid mixed-up data accesses and
race conditions, even possible dead locks. If it is missing or not properly
initialized, bad things might happen, especially in situations where that
is very difficult to track down...

The data structure is defined in "kernel/mselibc.pas", and the pertaining
section is this:

const
 __SIZEOF_PTHREAD_MUTEX_T = {$ifdef CPU64}40{$else}24{$endif};
type
  Ppthread_mutex_t = ^pthread_mutex_t;

{$ifndef netbsd}  
  pthread_mutex_t = array[0..__SIZEOF_PTHREAD_MUTEX_T-1] of byte;
{$else}
  pthread_mutex_t = record
 ptm_magic : dword;
 ptm_errorcheck: char;
 ptm_pad: array[0..2] of char;
 ptm_interlock: char;
 ptm_pad2: array[0..2] of char;
 ptm_owner: pointer;
 ptm_waiter: pointer;
 ptm_recursed: dword;
 ptm_spare2: pointer;
  end;
{$endif}

Well - for (at least) netbsd this defines a record of size _28_ or 40 bytes
in size, PROVIDED the mutex record is byte-aligned in netbsd. If that
was NOT the case, this definition might be out of order and possibly too
small in size, depending on the declaration. Thus, accesses _may_ cause
"irritations" to the system, making it behave erratically.

Sorry, I don't have any access to a netbsd system right now (would have to
find one and install it in a VM), so I cannot test whether this bears any
relevance to the problem. I only suspect that it might be able to cause
problems in some situations, and it should be expected to do so for use on
older, 32-bit, machines.
Just warning.
(And, you know, I was bitten by a well-meant "enhancement" to the db stuff
myself. I'm going to build a pertaining sample application now to test this
myself, and I do have some use for one anyway.)

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Save forms to bitmaps?

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Wed, 9 Aug 2023 00:12:27 +:

> >> Lagprogramming sent me PMs and agreed to share it with you.  
> 
> > Nice, it seems they are interested in some coopertion, then.
...
> Hum, Lagprogramming is a user of Lazarus forum who sent me, via PM, some

Fine, but that does mean that is only ONE guy, and not a larger project?
Sounds quite obscure, and getting worse...

> For the current "save forms to bitmap" he was responding to a post about
> framebuffer console and mentioned msegui. After he sent me some PM about

And what about the Lazarus function you mentioned some time ago? Why does
he ask for an equvalent for msegui, when he's going for Lazarus as you
write elsewhere, when it's already available for that?

> how to do it for msegui. It would be great if he jumps deeper into
> msegui, maybe begin to like it and then expands it.

This might be nice, presumed he REALLY wants to endorse msegui.

> But I have to confess that I dont understand perfectly his goal.

Yes, quite obscure indeed. Especially regarding the fact that there's the
"perfectly" viable function of X11 using a framebuffer driver. (And Linux
[maybe BSD Unix, too] is the only system using a framebuffer I'm aware of
- does Windows have something similar at all?)
Very muddled affair...

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Save forms to bitmaps?

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Tue, 8 Aug 2023 10:48:35 +:

Oh yes, and another remark, too: the msegui graphics implementation
obviously is based _heavily_ on X11 internal function for Linux and the
Windows GDI functions for Windows. That might mean that an adaptation to
_their_ system will either require the implementation of even the lowest
level graphical primitives separately or, if they do have them done
already, a full specification of the programming interface functions they
provide. Plus, probabely, "some" newly to develop "glue" code.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Save forms to bitmaps?

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Tue, 8 Aug 2023 10:48:35 +:

> Lagprogramming sent me PMs and agreed to share it with you.

Nice, it seems they are interested in some coopertion, then.
But I'm not yet clear about what "Lagprogramming" really IS or what their
gaol might be. Are they trying to develop another, competing, windowing
system like X11 and Wayland, even if that should only support the
framebuffer console (but you mentioned windows, seemingly multiple
freefloating ones), or is it meant to create a different graphical user
interface, somewhat in the way of Android's, or something different
entirely? (I think I really should fire up ol' firefox for some research
on the stuff...)

> I've read the mailing list discussion regarding saving rendered form
> bitmaps and framebuffers. Maybe the following information is useful to
> you. If you need a system function free backend in MSEgui you need to

Well, that's quite a lot of stuff. Is that meant as something like a list
of required interface functions? The "gdf_" ones then might be the names
their code is built on and wants to call, while the "gui_" ones look like
the list of interface functions from msegui's Windows compatibility units,
notably, in the "kernel" subdirectory, mseguiintf.inc, msegui.pas and
windows/mseguiintf.pas, that I identified as the most probable anchors for
adaptation to some other graphical system, although they list a host of
other functions as well. Did they possibly just do a "grep" on functions
and procedures starting with "gui_" for this second list?
I didn't compare their list of functions with those I had found, though,
so I cannot really be sure they're compatible. But it WILL require quite
some more information concerning the programming interface to be able to
attempt a viable implementation. Also, it's by no means clear yet what
their system provides and what it doesn't, i.e. what restrictions have to
be observed concerning library and system service use and other things.
Much work to do yet, so.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] INITIALIZATION SECTION

[Sieghard via mseide-msegui-talk]

Hello mohamed,

you wrote on Fri, 4 Aug 2023 08:55:13 +:

>  Finaly I opted  for the solution of scanning an array of
> TCUSTOMEDITDATAEDIT .

Depends on what, exactly, you want to effect. If it's only about selecting
a prebuilt set of fields, using an indexed array of fields might be a good
first step. To possibly avoid scanning all fields, it's also possible to
construct a set of relevant indices and using this in a for loop to access
the fields from the array, like so:

VAR
  selection: SET OF indexvalues;  // what ever these are...
  fieldindex: indexvalues;
  fields: ARRAY [indexvalues] OF ;

  selection:= ;
  FOR fieldindex IN selection DO  (fields [fieldindex]);

You don't have to check every possible index value with an "IF" condition,
the FOR loop can do that by itself, as an fpc extension to "basic" Pascal.

But I don't know whether this can be of any use to you, as I don't have a
clue what your goal might be - these are just theoretical considerations.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Save forms to bitmaps?

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Thu, 3 Aug 2023 23:49:31 +:

> Everybody who gives attention to msegui is important (but maybe not for
> msegui's persistance)...

Well... I'd not count a lot for people not wanting persistance of their
tools. But otherwise, sure, the more users, the better persistance. But it
can be a chore too.

> >If so, it MIGHT be useful to tackle the chore...  

> Yes, that is the best solution (and "they (Lagprogramming)" seems very
> skilled so it will be a funny game for him...).

Who? "Lagprogramming"? Never heard about it/him/them...
So I don't have a clue what this might mean at all.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] INITIALIZATION SECTION

[Sieghard via mseide-msegui-talk]

Hello mohamed,

you wrote on Thu, 3 Aug 2023 15:46:20 +:

> In my case , replacing :
> var frmInfotiersfo: tfrmInfotiersfo; aR1:array[1..2] of tcustomdataedit;
> oCustEdit:tcustomDataEdit; with
>  const   aSum set of tcustomdataedit = [ Price, Amount .] and then I
> can do
> 
>   if oCustEdit in  aSum then  sumField( aSum[?], n);

Just asking: Is this application code or is this an internal part of msgui?
If this was application code, could you make do with something like this:

TYPE
  app_field = (Price, Amount ...);
  aSum: SET OF app_field = [ Price, Amount ... ];
  oCustEdit: app_field;
VAR
  frmInfotiersfo: tfrmInfotiersfo;
  aR1: ARRAY [Price..Amount {aSum?}] OF tcustomdataedit;
...
and later use it like
...
  IF oCustEdit IN aSum THEN sumField (aR1 [oCustEdit], n);
...
i.e. doing the set operation on an enumerated index variable and using
that to select the appropriate field  That's how I would approach such a
problem, anyway.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Note at compile time FPC ver 3.2.2

[Sieghard via mseide-msegui-talk]

Hello mohamed,

you wrote on Tue, 25 Jul 2023 16:55:43 +:

>   I got this note:
> 
>   frmbasepage.pas(98,6) Note: Call to subroutine "operator :=(const
> source:Currency):Variant;" marked as inline is not  inlined.

This isn't a msegui unit - not that I could find it. And there's no
such operator definition to be found in msegui either, as far as I can
tell. This must be an internal declaration within fpc then, or it's an
application definition for a special (assignment) operator.

> iS IT POSSIBLE TO CLEAN THAT.

Well, it's only a NOTE, not even a warning, so no bad consequences to be
feared. Everything will still work as intended. It just means that the
compiler decided to issue a subroutine call to the operator implementation
instead of inserting the function body lit(t)erally.

If you have access to the declaration of that operator, you could remove
the "inline" clause. On the other hand, it's only a hint, nothing tp
bother. Inlining is not a strong feature anyway, and can be ignored by
the compiler "as it sees fit". Indeed, the documentation to fpc (ref.pdf,
p.221) says in section "14.9.4 inline" in the remark there:

"1. inline is only a hint for the compiler. This does not automatically
mean that all calls are inlined; sometimes the compiler may decide
that a function simply cannot be inlined, or that a particular call
to the function cannot be inlined. If so, the compiler will emit a
warning."

So, no problem here, or what was the reason for your question?

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] ERROR DBFILTER.PRJ

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Mon, 17 Jul 2023 12:38:31 +:

> I think there is only one db-msegui guru and it is Med. ;-)

Well, what does he think of the case then? Maybe he should resolve the case
finally then?

> >I apologize for the trouble I caused.  
> 
> You did not cause any trouble, Med has directly found the problem.

Well, no, it WAS trouble, causing the withdrawal of the latest issue.
I really should have investigated the effects of the "safe guarding"
statements much better, and even now I'm not definitely certain that
the one in "mmysqlconn.pas" is safe, as the case statement is really
confusingly set up, but definitely doesn't cover all defined states.
I just couldn't find out whether the undefined ones might at all occur.

> Also I keep all your fixes about mse_dynlib, so part of your fixes are
> commited. The only trouble could be if nobody care anymore of msegui.

Well, there's another place where "some" work ought to go yet, as it's
still lacking a method to dynamically extend the translation data base.
So it's still restricted to statically instantiate all forms requiring
translation at application start up, taking up more memory than neccessary.
(Well, on the other hand, one COULD argue that this sped up things some...)

I also would moan quite a bit if mseide-msegui should fade away. It was a
much earlier viable means to build useful GUI applications with fpc than
even Lazarus, which was nearly unusable when I started building my main
msegui project, around 2008-9, nearly a quarter century ago!

Thank you for your work, AND for your persistance!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] ERROR DBFILTER.PRJ

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Tue, 11 Jul 2023 22:21:43 +:

> >(As the initiator of the trouble, I'll probabely have the duty to attack
> > the chore, I'm afraid...)
> 
> I fear it too because my level of knowledge of db-msegui is very low.

Concerning your knowledge of that part see my previous comment...

Anyway, I did some scrutinizing of the pertinent code, and found that the
only place where mohamed's message might probably, possibly, arise, is the
"safe guarding" else clause in "msedbedit.pas" where the navigator buttons
are handled. To test an additional condition for filtering, the button
selection case statement was split in two, which pass through the values
that are not applicable. So, the original was alright and should be kept
as it is now.

The case is a bit different for the other occurrences of the "guarding"
exception, but due to several enumeration label redefinitions / renamings,
it is very confusing what should be accepted and what might constitute an
error. So I plead for keeping the "safe guard exception" for the unit
"mmysqlconn.pas" FOR NOW, as long as it does no harm. Of course, should a
problem arise, the case ought to be examined, even though the exception can
"in principle" be caught and handled by an application program, if need be.
But I agree that it is not at all elegant to have an application cater for
perfectly admissible conditions.

Concerning the unit "msebufdataset.pas", it should not be possible to
trigger the "safe guarding" exception, although the type of the value has
values capable of doing so. So, it might be advisable to also keep the
exception here, as it cannot normally do any harm, but could help finding
errors in unusual cases.

That's for now what I could find out about the cause of the troubling
message about the newly introduced error in msegui's db code.
I apologize for the trouble I caused.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Release MSEgui 5.8.2.

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 14 Jul 2023 14:59:09 +:

> So, using -O3 -OoNODFA gives a mseide without problems.
> Even more, -O4 -OoNODFA is ok too!
> 
> Conclusion: msegui can use all the optimizations, appart DFA (does
> anybody knows what does that DFA optimization?).

The two documentation files "prog.pdf" and "user.pdf" of fpc both agree
that it should mean "Data Flow Analysis". But there's no hint at what that
might effect beyond that statement. It might mean a mechanism that tracks
the use of variable data and tries to avoid multiple evaluations or
unneeded memory transfers or something similar. And seemingly guesses
wrongly sometimes...
No, wait, there IS some more information. In "prog.pdf" (Programmer’s Guide
for Free Pascal, Version 3.2.0, February 2020, p. 132) they say:

"• Level 2 (-O2) enables the assembler data flow analyzer, which allows
   the common subexpression elimination procedure to remove unnecessary
   reloads of registers with values they already contain."

So that's about what I suspected, but on the level of registers rather than
variables.
(Sorry, I don't seem to have any fpc 3.3.1 documentaion installed by now.)

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] ERROR DBFILTER.PRJ

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Tue, 11 Jul 2023 22:21:43 +:

> Hello Sieghard.
> 
> >(As the initiator of the trouble, I'll probabely have the duty to attack
> > the chore, I'm afraid...)
> 
> I fear it too because my level of knowledge of db-msegui is very low.

Huh! You probabely know a whole order of magnitude more about it than I do
I'm not even a casual user of that part of msegui. The only db programs I
DID create (for a customer) were Lazarus based, and that's probabely a
comletely different world of database programming...
I only came about these units because, of course, they're used by the IDE
to provide its db components. And that's where it spew out a lot of
warnings concerning incomplete case value coverage.
So, be prepared that it will take QUITE some time until I came about
finding all of the questionable cases, where a message would be in order
and allowing for the required ones, which ought to be passed through.
In the meantime, it would be suffice to use the approach from my last
message, i.e., just replace the "else" branch of the pertaining case
statments by an empty one to "make the compiler happy", as you like to
state it (i.e. avoid the overly [?].picky compiler warning from fpc 3.3.1).

Anyway, thank you for your good work and swift reaction!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] ERROR DBFILTER.PRJ

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Mon, 10 Jul 2023 21:09:01 +:

> I did read your post but sadly I did not find yet the time to jump into
> your code. I will try to do it asap.

There is no code above the one provided previously - just the explanation
of the reason for the reported error messages. Well, and a possible "fast
fix" for them, albeit a probabely incomplete one.
But still, doing it thoroughly WILL take its time, as this would require to
test all the occurrences of the problematic message, and maybe even those
of the other one, and making CERTAIN that there will be no false triggers.
(As the initiator of the trouble, I'll probabely have the duty to attack
the chore, I'm afraid...)
Sorry for the problem.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] ERROR DBFILTER.PRJ

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 7 Jul 2023 19:48:36 +:

> @Sieghard: there is problem with the last change in  /db from your
> mseide-msegui-shadow.zip file. So I reverted to previous code.

Just asking to make certain you received my posting from Sat, 8 Jul 2023
22:38:14 +0200 toward the issue. Do you have further information?

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release?

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Sat, 10 Jun 2023 17:37:44 +:

> Note that with NetBSD using the "su" command in a Xorg terminal will
> destroy the pam config (for login+password). And you will not be able to
> login anymore (and must reinstall all the system).

Ihat's a really _very_ bad thing...

> So for all the things you need a root access, terminate the Xorg session
> to come back to terminal-no-gui, login as normal user, then use the "su"
> command to do the things that need root access.

Does NetBSD's Xorg NOT have the LeftAlt-Ctrl-F hot key function to
switch to a text mode console? Or is that just disabled by default, as
many Linux Xorg/Gooey^WGUI installations do it by now, somewhere setting
a "ServerFlags" section 'Option "DontVTSwitch""true"'?

(There's a program, "chvt", that can do the switch too, but that requires
root rights to be used, so it's useless here.)

Creating a "/etc/X11/xorg.conf" file with just the contents
"Section "ServerFlags"
Option  "DontVTSwitch""true"
 EndSection"
_might_ suffice, but it may neccessary to also include a line like
'   Option  "ServerLayout" "X.org Configured"'
for Xorg to accept it.

Be sure to scan Xorg's log file (Xorg.0.log) whether it had the intended
effect or just rose a warning or an error. Read the Xorg man page!

> Or do this after boot, before to run "startx" command.

You do not want to (re)boot a Unix for maintenance purposes only! Do you?

(Ooops, THAT was looong-winded thread!)

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release?

[Sieghard via mseide-msegui-talk]

Hello vasi,

you wrote on Thu, 1 Jun 2023 12:35:27 +0300:

> Thank you Sieghard, much appreciated! I was able to compile msegui using a
> command from Fred's ideU cimpiling directions.

Ok, fine.
If you'd like t osee my script anyway, give notice. I can put it on my
mseide Web page for you (and maybe others), then.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Save form as bitmap?

[Sieghard via mseide-msegui-talk]

Hello Fred,

vous ecrit au Tue, 21 Mar 2023 01:06:41 +:

> The only easy way I found was using BGRABitmap:
> 
> procedure TfrmMain.CopyScreenForm;

Thank you for the information - so it looks like there's indeed no easy
way to get at the contents of an msegui window from within msegui (so to
speak)? Your procedure looks like it used the same method as any screen
grabber software does, namely read the display buffer directly. That way,
it should be hampered like these by overlapping windows or partially
outlying areas.
Anyway, I'll test your method and see what can be done with it.
(Although, by now still at least, I wonder whether this is available on
Linux at all, as all references I found seem to describe it as stemming
from Microsoft, i.e. from the Windows world.)
BTW, lastly, I even got a smallish success. I found an arrangement of
procedure / function calls, supported by a couple "class helper"s, that
didn't just spit out some error message or even crashed the program, but
that DID produce a correctly typed bitmap file of even something like the
correct design time size. It still didn'r contain any window content, just
a black rectangle, though. So, this might eventually lead to something,
but it's certainly still quite a stretch to go...

Anyway, don't worry, and keep up the god work!
And thank you again for your information.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Save form as bitmap?

[Sieghard via mseide-msegui-talk]

Hello Fred,

vous ecrit au Mon, 13 Mar 2023 17:18:53 +:

> LCL allows reading form's rendered bitmap by accessing
> TForm.GetFormImage. For example you can save the bitmap in a
...
> thing in msegui? Is it possible to somehow SaveToStream or SaveToFile the
> bitmap rendered by a msegui form?
> 
> How to do this with MSEgui or BGRABitmap ?

Question: did you get some response to your request already, or even a
solution to the task?
As this looked like an interesting challenge, and since I just can spend
some spare time to tackle it, I set out to try to implement such a function
for msegui. On the outset, it didn't seem to difficult, as there are many
functions concerning the manipulation of such data. But on closer
inspection, the chances dwindled away quite fast, as there seemed to be an
unbridgebale gap between the real image manipulation units, that also can
read and write image data and files, and the display bitmap functions
needed for drawing to windows on the screen. But it became even worse, when
I dug deeper, scrutinizing the function implementations. Well, trying to do
so, at least, as most of then - didn't even HAVE an implementation! They
are cleanly listed in the object interface definition (mostly deemed
"private", a few "even" protected), but in the implementation section, the
function header was - is - most everytime followed by an implementation
with only the line "  // dummy" in its body... Very disappointing,
So, for now, I practically gave up on a (hig level) implementation attempt,
as I'm afraid I'd not be able to do all the "grunt work" to fill up this
field of pitfalls, featuring a mass of gaping holes.
On the other hand, of course, all these function aren't really vital for
the function of a regular application built from msegui, as capturing of
graphical constructs doesn't seem to have been close to Martin's primary
target of application. Anyway, sometimes this could be used to advantage,
for documentation purposes e.g., even when it's not nomally needed. Even
for my "big project", I was asked to provide such a function to ease
documentation, although as a fast solution I just installed one of the
(many) available screen capturing programs, callable by a special funktion
key combination from within the application. That mostly did the job there,
but it did have it's problems, either...

So, for now at least, no solution from me, so I can just ask whether
someone else might have already succeeded?

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Notes & Warnings

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Fri, 10 Mar 2023 17:39:18 +:

> Argh, in previous post, please read this:
> 
> I used indeed the last release of MSEide:
> https://github.com/mse-org/mseide-msegui/releases/

Well, yes, that's how it reads - what's wrong with it?

...
> Afaik, if no mode was defined in the unit, the default mode is mode "FPC".

The default mode is the one defined in fpc's basic configuration file.
It's to be expected to be "fpc", but it could be anything fpc recognizes.

> And with this mode, you have to add minimum {$modeSwitch exceptions+} and
> so fpc accepts the "raise" statment.

So this MIGHT not be sufficient, even not recognized at all.

> > Inserting the line "{$ifdef FPC}{$mode objfpc}{$endif}"
> 
> Yes, it is, imho, the best solution ( and remove the last "modeswtichs"
> in commit).

It's the safe method, after all.

Thank you.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Notes & Warnings

[Sieghard via mseide-msegui-talk]

Hello Fred,

vous ecrit au Fri, 10 Mar 2023 00:19:31 +:

> Ooops, in previous post I did not get error because I used the last
> commit of msegui.
> 
> So, without the "modeswitch" I get that error, see picture:
> 
> https://user-images.githubusercontent.com/3421249/224190166-757b36da-6a91-47f2-9466-d52eaf63d92f.png
> [https://user-images.githubusercontent.com/3421249/224190166-757b36da-6a91-47f2-9466-d52eaf63d92f.png]

Ok, I can see it. Funny after all, and this should definitely NOT occur,
as all the components of mseide DO include a mode setting statement to
enable "objfpc" mode.
But - could it be that the ide you used (I presume it was the original
mseide) did try to COMPILE this file as a unit on it's own? It's named
".pas" after all, and that could have triggered such an action.
It probabely doesn't occur on a normal compile, when the mode settings,
as seems to be the case, are "carried over" between compiles. But the
mseide (and probabely your ideU, too) might call the compiler separately
for each unit file, and thus tried to compile the "FieldTypeError" unit
on its own. As this does NOT contain an "objfpc" mode setting, the modes
"class" and "exception" possibly weren't enabled, and thus the compiler
balked out. And that's the rather certain explanation for the effect -
I just tried to test this assumption, opening the project with the ide
(usually I compile it without it) and EXPLICITLY adding the file
"FieldTypeError.pas" to the edited files list. Then started the compile,
and, after a while, it INDEED failed with the very same messages as you
got. Inserting the line "{$ifdef FPC}{$mode objfpc}{$endif}" remedied
this, as expected. So doing this would be the real solution.

Or, another option might be to change the compile strategy built into
mseide to ONLY call the compiler ONCE with the project's MAIN FILE.
There's even an appropriate entry in the project file ("mainfile="), but
it doesn't seem to be used. Or, is it? I didn't research this further.

BTW, maybe the "Check method headers" could be responsible for this
behaviour? I tried it, but this doesn't affect this effect, apparently.
At least not definitively... After some playing around, the ide wasn't
"willing" to compile itself without error anymore, so it's not possible
to say whether this option has any effect on the problem. So inserting
the above mentioned mode-setting line will be required.
(BTW, during my tests, the ide suddenly kept insisting to write to some
file named "/home/fred/mseide-msegui/lib/common/kernel/msegui.pas" when
closing the file "FieldTypeError.pas", but when I created the directory,
nothing was written. Seems to be a "side effect" of Martin's creative
relativism pertaining paths in project files...)

(And, BTW, I found another problem with mseide's error handling that I
mean to have seen before already: on encountering an error, the ide loads
the pertaining source file, even if it already IS loaded. This, in the
following, can cause a number of "interesting effects", especially when
you're debugging your program and try to find some specific position. I
don't fully remeber what I got, but I found it neccessary to ALWAYS close
a file containing an error and breakpoints simultaineously [IIRC].)

Well, the "BTW"s normally won't hurt as they won't occur, perhaps except
the last one. It's just that I stumbled over them, and wanted to mention
what I found.

And, this time I didn't upload a new version of the affected file, leaving
it to you to insert the mode setting statement for another commit because
of its triviality.

Thank you for your report, and keep up your good work!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Notes & Warnings

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Mon, 6 Mar 2023 01:20:25 +:

> By the way, in last mseide-msegui commit, I added {$modeSwitch class+}
> and {$modeSwitch exceptions+} in FieldTypeError.pas otherwise MSEide did
> not compile. There was complaining about "Raise" indentifier unknown.

Interesting, I just tried this (recompile mseide) with the _old_ library,
i.e. without the "modeswitch" statements, and I didn't get a complaint.
Under _what_ circumstances did they occur for you? I compiled with my
"usual" settings, or rather without any special settings. But I didn't
try compiling anything with it yet, and I didn't use any db components.
On the other hand, as you wrote, it "did not compile", I assume the
compiler already complained when you compiled the ide _itself_?
Not so here, though.
Could you give me some hints as to what to do now? Thank you.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Notes & Warnings

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Wed, 8 Mar 2023 11:22:34 +:

> You do not need to go to the mseide-msegui site.
> Just use this link and you will get the last source with last commit  (it
> is automaticaly updated):
> https://github.com/mse-org/mseide-msegui/archive/refs/heads/main.zip

Ok, fine - that way I can let my machine do it. I think, that's what
machines should be used for, do you?

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Notes & Warnings

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Tue, 7 Mar 2023 13:00:20 +:

> In previous post, the commit is (previous was a other commit):

Well, thank you...
I think, I'll best look directly at the github page and get the there and
then current version...
I haven't looked at the issue yet.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Notes & Warnings

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Mon, 6 Mar 2023 01:20:25 +:

> By the way, in last mseide-msegui commit, I added {$modeSwitch class+}
> and {$modeSwitch exceptions+} in FieldTypeError.pas otherwise MSEide did
> not compile. There was complaining about "Raise" indentifier unknown.

Interesting. The version I downloaded doesn't have them - yet?
Anyway, I shall check that.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Notes & Warnings

[Sieghard via mseide-msegui-talk]

Hello Fred,

you wrote on Wed, 1 Mar 2023 19:45:40 +:

[stockobjects.extended crashes application]
Thank you again for reporting this Error. Indeed, this was my fault, I
had introduced a non-terminating recursion there instead of providing, as
planned, a safe initialization. In fact, the functions above the erroneous
ones were already modified the same as you found neccessary  for the last
two, and you were right doing so. Still, it might be possible to call one
of those functions before everything is fully initialized, and so I added
a non-recursing initialization call to all those functions. Testing with
your ideU, including the insertion/deletion operation that crashed before,
showed no problem any more, even for the "mse_dynpo"-enabled version.
Thus, I uploaded the unit file (uncompressed, i.e. "msestockobjects.pas"
directly) to my usual exchange web page for you.

Thank you again for your continuing good work!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Notes & Warnings

[Sieghard via mseide-msegui-talk]

Hello Fred,

vous ecrit au Wed, 1 Mar 2023 19:45:40 +:

> >   result:=   lang_extended [ord (index)];"
> > in unit "msestockobjects.pas". As one of my goals was to get rid of
...
> I did this because if I keep your modif, when trying to delete a line
> from a grid, the application crash.
...
> It is not the case when using lang_extended [ord (index)].

Meanwhile, I tested that, and indeed, there's a crash when compiled with
"mse_dynpo", using the compatibility function. I'll have to find out why
this happens, the compatibility functons are supposed to initialize
themselves when called the first time. This doesn't seem to occur here,
and that should be repaired. I'll see what I can do and report.

Thank you for the information, all the best to you!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---




___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Notes & Warnings

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Tue, 28 Feb 2023 00:10:25 +:

> Dear Sieghard your mseide-msegui-shadow fixes are in GitHub via
> commit 1f52efa. I tested it and all is ok, many thanks for all those
> warnings away.

Thanks, not worth mentioning, surely not so prominently. This was just
out of anger about so many unneccessary warnings, prone to drown out
those that really _are_ relevant and need to be fixed.

> I have seen you added /db/FieldTypeError.pas to manage error with db
> field type errors and updated all units to use it. Nice and very
> usefull.

Well, yes, indeed... I really had to check and find out what that means.
And, indeed, that's a small hack I introduced to have better control
over database operations. I'm certain I DID miss a number of instances
where it might be of use, and probabely left out (of ignorance) a few
places which might also warrant a hint. Fine when you deem it useful.

> Thanks again and have perfect days.

Thank you for your good work, it's fine to get notice from you again.
I was already about asking myself whether mseide-msegui might have
gone under already. Of course, I got me your latest version and looked
for the modifications, finding that I already had introduced most of
them in my working copy.
I just noticed two occurences of an insertion,
"// result:= stockobjects.extended [index];
   result:=   lang_extended [ord (index)];"
in unit "msestockobjects.pas". As one of my goals was to get rid of
the direct use of the "lang_"-arrays, I wonder why these might be
required?

But anyway, I'm really glad to see that work on mseide-msegui is still
in progress and it is active and evolving.

Again, thank you for your good work, I wish you well and good luck!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Notes & Warnings

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Thu, 15 Dec 2022 13:13:58 +:

> I have copy the file from Sieghard-site as attachment in a
> MSEgui-issue. You can download it from here:

Thank you for doing so. I take it that you DID check the validity of
the modifications before publicicing it. There will be huge holes, and
I didn't even care to find them. Additionally, I didn't take any
measures toward such things as automatic tpe conversions that DO NOT
risk loss of precision or data (like from Unicode to ANSI strings).
And I purposely left in a couple warnings, e.g. for the variable
"win_gc" ued in the linux "mseguiintf.pas", which might prove useful
for some later extension.

> https://github.com/mse-org/mseide-msegui/files/10237207/mseide-msegui-shadow.zip

And, BTW, this is not a full set of the library units, just the
modified ones, and I seriously recommend to everyone wanting to
experiment with them to make a backup of the original ones before
substituting these modified ones!

> @Sieghard: many thanks for that hard-boring but highly usefull work
> that I will deeply test asap.

I hope it can be of some use. At the very least, if it doesn't
introduce new error, it should remove distracting "Notes:" and, more
important, "Warning:" messages during compilation. The latter were my
main target, because a good number of them hinted at possible problems.
After all, the tool used to work on the source, the compiler, has
changed a lot since the beginnings of the project, and this should be
taken into account. ANY warning message should be taken serious and
checked for possible bad consequences, in my opinion.

So, again I have to say "Thank you" for your kind consideration, 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
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Benchmarks.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

following the remark, "I'm always struck by a good number of
compiler messages" (i.e. Note: and Warning:), made in my message from
Wed, 30 Nov 2022 01:11:31 +0100, I now made an attempt to "remedy"
these by eliminang their respective causes, as much as possible.
Well, I'm QUITE a bit disappointed about the diagnostic abilities of
the "new" fpc 3.3.1 now. It's degraded a lot compared with fpc 3.2.2
as to recognize variable usage. That is, IF fpc 3.2.2 did care about
that at all, of course...
fpc 3.3.1 moans about an (intermediate) variable being assigned to,
BUT NOT USED, if it is only used as an argument to some function or
procedure. I.e., it IS in fact used, but that use is not recognized
by fpc 3.3.1. Nearly all of the "Note:" messages of the compiler are
of this kind, which is distracting.
Concerning the warnings, there's even a similar kind of misleading
messages: "Warning: Function result variable of a managed type does not
seem to be initialized", which mostly arises from the fact that the
initialization IS done, only by a procedure getting the result variable
passed as an output or var type parameter. 
By now, I found just a couple possibly truely detrimental problems in
the msegui library files, but I've put aside ALL of the string
conversion issues from a lesser type to "UnicodeString", keeping only
the other direction, whcich claims "potential data loss". But these
still are numerous, which takes some time...

I'll report when I'm done, and will make the result available on my web
site, as usual.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Benchmarks.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Mon, 28 Nov 2022 23:29:41 +:

> >Yes, it has improved a whole lot compared to fpc 3,2,2, ESPECIALLY on
> >floating point operations.
> 
> In my case, because using extendly float calculation in uos sound
> library, it is a big plus.

My tests don't use really heavy calulations, a sI wrote, just a simple
prime sifter, performed very often. I.e., the control operations
probabely outweigh the calculations by a big factor, drowning out the
floating point performance noticably.

> > With integer operations, it has slowed down
> > appreciably, by about 30% (i.e. it takes nearly 50% LONGER).
> 
> And this is a few sad ( and difficult to undertand, maybe change all
> integer calculation into float and then round it, should be faster? )

Yes, this IS quite sad, and it's hard to imagine a mechanism. It might
even suggest a noticable degradation of control function performance
as its cause, which would be very bad, because this would compromise
much more applications than could benefit from the better floating point
performance. (And, interestingly, the llvm-based fpc 3.3.1 isn't much
better either.)

> Very interesting benchmark.

Not so much, just a q performance check aimed at the special topic of
numeric operations. Perhaps one should also test the control flow
operations; perhaps a loop producing all permutations of a given string
might work?


-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Benchmarks.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Sun, 27 Nov 2022 23:04:08 +:

> fpc 3.3.1 does better than fpc-llvm 3.3.1...

No, that is not the case. But llvm-based fpc 3.3.1 is only marginally
faster than plain fpc 3.3.1 on integer calculations and not much faster
(perhaps around 20%) on floating point (doubles) operations.

> So fpc 3.3.1 is very good

Yes, it has improved a whole lot compared to fpc 3,2,2, ESPECIALLY on
floating point operations. With integer operations, it has slowed down
appreciably, by about 30% (i.e. it takes nearly 50% LONGER).

> or fpc-llvm 3.3.1 dont use yet all the power of llvm
> or llvm is a joke.

I'd not say hat, llvm is yet another C/C++ compiler for many systems,
and it probabely has its place. And, llvm certainly has a place as the
tool to build compilers for other languages that it is.
There may be established "competitors" it DOES improve a lot against,
e.g. gcc is not usually called notoriously speedy.
But fpc, i.e. fpc 3.3.1, obviously is not one of them. And what these
results seem to display is that it is probabaly a bad idea to compare
a variant of an advanced version of an application with an older plain
version of it. E.g., fpc 3.2.2 and fpc 3.3.1 llvm. They DO NOT COMPARE.
The correct comarison always is between corresponding items, i.e. both
the plain versions (fpc 3.2.2 vs. fpc 3.3.1) or - if available -
equivalent variants (fpc 3.2.2 llvm vs. fpc 3.3.1 llvm), which do not
exist for fpc.

So, this seems to suggest that the llvm version of fpc is not worth
switching to it, for now at least, for fpc 3.3.1. This could change in
the future, but it WILL require a thorough examination of the results.
Much more thorough even than I did here, if it should be definitive.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Benchmarks.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Sun, 27 Nov 2022 12:29:45 +:

> Note that llvm "is" optimization, without it there is no sense to use
> it. I did some test with float calculations and the difference was
> big (much better for fpc-llvm) when adding -O3 or -O4 parameters.

Well. I just modified my test (a simple prime calculator) to use floats
(doubles, to be exact) for its calculations, and that's what I got:

floatprime_322_O3:  floatprime_331_O3:  floatprime_llvm_O3:
real0m2,591sreal0m0,364sreal0m0,290s
user0m2,584suser0m0,317suser0m0,225s
sys 0m0,006ssys 0m0,047ssys 0m0,065s

floatprime_322_O4:  floatprime_331_O4:  floatprime_llvm_O4:
real0m2,614sreal0m0,367sreal0m0,305s
user0m2,610suser0m0,307suser0m0,244s
sys 0m0,003ssys 0m0,060ssys 0m0,061s

For reference, these are the integer calculation values:

prime_322_O3:   prime_331_O3:   prime_llvm_O3:
real0m2,317sreal0m3,491sreal0m3,336s
user0m2,262suser0m2,787suser0m2,661s
sys 0m0,054ssys 0m0,703ssys 0m0,674s

prime_322_O4:   prime_331_O4:   prime_llvm_O4:
real0m2,304sreal0m3,497sreal0m3,353s
user0m2,261suser0m2,769suser0m2,618s
sys 0m0,042ssys 0m0,727ssys 0m0,733s

In both cases, the "322" means "standard" fpc 3.2.2, "331" means
"plain" (not llvm-based) fpc 3.3.1, and llvm fpc 3.3.1 llvm-based.
"O3" stands for -O3, and O4 for -O4 optimization.

So, I'm not so sure. It seems that the new fpc compiler, 3.3.1, became
somewhat WORSE on integer calculations, but was enormously enhanced for
floating point operations. In fact, it's nearly on par with the times
of the llvm-based version, although the "plain" 331 was built long
before I even thought of playing with llvm.
This does even suggest that the enhancements seen with the "llvm"
version of fpc MIGHT be mostly due to enhancements of fpc itself, and
not so much be caused by better performance of llvm-generated code.
Now, I think it might be of interest to know whether your claimed big
difference of performance still holds when you compare the results of
your test code compiled with "plain" fpc 3.3.1 and it's llvm-based
version.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Benchmarks.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Sun, 27 Nov 2022 12:29:45 +:

> > The error is the omission of a "-"
> > sign in front of the switch "XlS",
> 
> Oooops, indeed, fixed just now in Lazarus forum.

Good. Does the version dependence also get mention there?

...
> > And got rather disappointed. The llvm-based compiler did WORSE
> > innearly all respects.
> 
> Yes, indeed, without any optimization, fpc-llvm does worse than
> "pure" fpc. All changes with optimization -O3 and -O4.

Well, I usually don't do much optimization. When an application is fast
enough and does what it should, optimizing it just increases the risk
of malfunctions, and debugging - i.e. finding the cause of a malfnction
- can become extremely difficult. And there's word that there ARE
malfunctions that ONLY occur at higher optimization levels...
But indeed, at -O2 llvm seems to come apar to fpc's speed, although
executable sizes still are a lot larger, around 40...50%.

> Note that llvm "is" optimization, without it there is no sense to use
> it. I did some test with float calculations and the difference was
> big (much better for fpc-llvm) when adding -O3 or -O4 parameters.

The question is whether this shows under the given conditions - if it
becomes noticible only with extensive floating point calculations, it
can have its area of application. But if that's not what you mainly
need, it might not be worth it. And if you're short of (disk) space,
llvm might even be detrimental.
But I think, I'll have to do some further experimentation yet.

Thank you for your comments.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Benchmarks.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Sun, 30 Oct 2022 11:47:17 +:

> Just by curiosity.
> 
> Has somebody already try fpc + llvm ?
> I have try to compile fpc for llvm but without luck.

You made me curious, and as I had meant to attempt to experiment with
this beast anyway, I now DID some testing. The description on the
lazarus forum by Jonas Maebe you posted here (Msg-Id:
db4p189mb2288e0679294ad86d17c1f10b8...@db4p189mb2288.eurp189.prod.outlook.com)
was very helpful to get it running, although it does contain some
misleading information and a true error. The misleading information AND
the error are in the part 'FPCMAKEOPT="-Clv13.0 XlS-13"' of the make
call for building the llvm version: The error iss the omission of a "-"
sign in front of the switch "XlS", so this should really read
'FPCMAKEOPT="-Clv13.0 -XlS-13"'. The mislesding occurs because of the
fixation of the llvm/clang version number to 13.0 resp. 13. On my
system the respective versions are 14.ß and 14, and I did try some
combinations and searched about for possible values for some time.
So to successfully compiling the llvm version of fpc, you ought to make
sure that the argument to "-Clv" matches the version of your llvm
compiler, and the one to "-XlS" matches the version of "clang"
installed along with it. These values are needed by the installation
step given further down in the instructions as well, otherwise
installation will fail.
Having both of these values set correctly, I was able to successfully
compile the compiler and its libraries and also install it at a place
where it doesn't interfere with the regular version(s).

Then I went on to do a little testing as to the advertised performance
of llvm-based fpc. I did some compilations and attempted a simple
timing test, using the programs I have lying around.
After surpassing the slight annoyance that the llvm-based compiler does
NOT provide any distinction whatsoever from its regular counterpart,
say, by a different version number or a unique conditional symbol, I
was able to produce executables for the fpc versions 3.2.2, 3.3.1 and
3.3.1-llvm.
And got rather disappointed. The llvm-based compiler did WORSE in
nearly all respects. The executable sizes were generally larger,
sometimes much larger, compilation took "forever" (more than 6 times)
compared to the regular fpc version, and at the - admittedly very
cursory - timing test I made, it performed worst of the 3 candidates.

These are the results I got:

FPC LLVM Timing Tests  So 27. Nov 01:43:13 CET 2022
=

Name: __
Application name
Compiler version - 322: fpc 3.2.2, 331: fpc 3.3.1, llvm: fpc 3.3.1 w/
llvm Compile time - seconds rounded to 0.1s

ideU:
=
unstripped:
-rwxr-xr-x 1 hardi 54441776 Nov 27 00:47 ideU_322_51.1s
-rwxr-xr-x 1 hardi 51500904 Nov 27 00:48 ideU_331_40.9s
-rwxr-xr-x 1 hardi 49185816 Nov 27 01:00 ideU_llvm_308.5s

stripped:
-rwxr-xr-x 1 hardi 14399536 Nov 27 01:05 ideU_322_51.1s
-rwxr-xr-x 1 hardi 14691408 Nov 27 01:05 ideU_331_40.9s
-rwxr-xr-x 1 hardi 20078184 Nov 27 01:05 ideU_llvm_308.5s

MSEclock:
=
unstripped:
-rwxr-xr-x 1 hardi 27384624 Nov 27 01:31 MSEclock_322_18.1s
-rwxr-xr-x 1 hardi 25756424 Nov 27 01:32 MSEclock_331_17.2s
-rwxr-xr-x 1 hardi 19898632 Nov 27 01:35 MSEclock_llvm_102.7s

stripped:
-rwxr-xr-x 1 hardi 6003088 Nov 27 01:38 MSEclock_322_18.1s
-rwxr-xr-x 1 hardi 6172720 Nov 27 01:38 MSEclock_331_17.2s
-rwxr-xr-x 1 hardi 8942120 Nov 27 01:38 MSEclock_llvm_102.7s

PO2MO:
==
unstripped:
-rwxr-xr-x 1 hardi 2162592 Nov 27 01:09 PO2MO_322_0.3s
-rwxr-xr-x 1 hardi 2057512 Nov 27 01:10 PO2MO_331_00.4s
-rwxr-xr-x 1 hardi 2141432 Nov 27 01:10 PO2MO_llvm_0.9s

stripped:
-rwxr-xr-x 1 hardi  927696 Nov 27 01:11 PO2MO_322_0.3s
-rwxr-xr-x 1 hardi  953200 Nov 27 01:11 PO2MO_331_00.4s
-rwxr-xr-x 1 hardi 1302840 Nov 27 01:11 PO2MO_llvm_0.9s

times:
- files
  -rw-r--r-- 1 6,1K msegui_ar.po
  -rw-r--r-- 1 6,7K msegui_de.po
  -rw-r--r-- 1 8,5K msegui_el.po
  -rw-r--r-- 1 4,9K msegui_empty.po
  -rw-r--r-- 1 6,5K msegui_eo.po
  -rw-r--r-- 1 6,7K msegui_es.po
  -rw-r--r-- 1 6,7K msegui_fr.po
  -rw-r--r-- 1 7,0K msegui_he.po
  -rw-r--r-- 1 6,5K msegui_id.po
  -rw-r--r-- 1 6,6K msegui_it.po
  -rw-r--r-- 1 6,6K msegui_nl.po
  -rw-r--r-- 1 6,6K msegui_pl.po
  -rw-r--r-- 1 6,6K msegui_pt.po
  -rw-r--r-- 1 8,1K msegui_ru.po
  -rw-r--r-- 1 6,3K msegui_zh.po
  101,897 B in 15 files

322 timed:
real0m0,067s
user0m0,024s
sys 0m0,042s

331 timed:
real0m0,069s
user0m0,020s
sys 0m0,049s

llvm timed:
real0m0,079s
user0m0,026s
sys 0m0,053s


Only the "unstripped" sizes were better - but these arent of much
significance, since applications robabely won't be deployed with all of
the debugging data contained, will they?
The timing tests comprised converting all of the "standard" .po files
into .mo files using the system "time" command. My machine was
otherwise "idle" during all of these runs, only performing the
"standard" system service 

Re: [MSEide-MSEgui-talk] New release MSEide+MSEgui 5.6.10.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Thu, 17 Nov 2022 15:01:29 +:

> Ha I think I remember now!
> It was because, on Windows, the list is filled with all the
> compatible fonts but it also include the alias-font names and so
> referts to a already font in the list. So the total number of font
...
How can these multiple references be recognized? If a name refers to
another entry and you can recognize this, it should be possible to use
the ability of fpc's lists to keep entries "unique", altough you might
have to provide some kind of "sorting" algorithm.
But keeping entries "unique" isn't difficult either, I implemented this
e.g. for the "fontlist" program (but don't remember whether I made it
available on my web site) and for the .mo file generator ("PO2MO").

Best wishes!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release MSEide+MSEgui 5.6.10.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Tue, 15 Nov 2022 02:06:19 +:

> I had the opportunity to fast test ideU compiled with your
> msegui-shadow on a Windows 10 machine this night. All seems ok, the
> list of languages is filled and if selecting a language, using PO
> files, all the layout uses that language, as espected. No crash, all
> happy. But if selecting "Use MO files instead of PO files" and
> selecting a language, it is always in English, no change in layout
> (but no crash).

Does this ONLY happen on Windows or is this a general problem? It might
also depend on the combination of compiler settings of "mse_dynpo",
"usemo" and perhaps also "useLibFontConfig". I suspect this to happen -
consistently and reproducibly - when "usemo" was NOT set on building
the program. Then, the neccessary functions probabely will not be
available, because they were not even compiled in, so there's probabely
no way to process the files in the first place.

This may be a good opportunity for using a conditional compilation
directive, to avoid confusing the user if the ability isn't available.
Oh, I just saw, I already DID insert such a directive, and it's really
trivial. In "conflang.pas", insert it there:

procedure tconflangfo.oncreat(Const Sender: TObject);
begin
  Visible := False;
 {$ifndef usemo}
 bousemo.visible := false;
 {$endif}
end;

Then the unavailable selection will be hidden on form creation and
nobody will be misled.
I just didn't bother to pack this together and put it on my web site
yet, because it's "only" a test bed for me and I had indeed forgotten
that I did introduce this detail at all.
But I've to correct me again - I DID pack the stuff together and put
it on my web site - it's in the file "ideU_fonts_284.zip", although
this contains only the modifications, not the full source.
(And I cannot tell you any more why it is so named - no more clue...)

> Sadly I did not have time enough to jump in the code with that
> machine, I will need to find a other Windows PC more disponible (or
> maybe you have a idea what is wrong).

I think the problem is what I described above, and that it is NOT a
speciality of the Windows version. But it depends upon whether you can
specify - or test yourself - how the compiler switch combinations do
affect the workings of the software. After all, they will, as they
should.

> But this has nothing to do (imho) about the code of msegui-shadow and
> is only related to ideU himself.

Not specifically to ideU, but to the licalization system in general. If
a part is not built, it "might" (will!) not be available...

> So the commit of msegui-shadow is also ok for Windows ( tomorrow I
> will do check for Linux rpi-arm/aarch64 ).

Thank you for all the work you do - as I wrote, I'm interested in the
aarch64 architecture, but I still don't have a sufficiently equipped
RaspberryPi running.

Many thanks for your good work!

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] GitHub discussion.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Thu, 27 Oct 2022 19:46:04 +:

> mseide-msegui/GitHub has a "discussion" feature:
> https://github.com/mse-org/mseide-msegui/discussions
> 
>  And there is some movement  there...

I saw it yesterday. Sadly on-line only. I.e., you have to chat while
your doors are all wide open...

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release MSEide+MSEgui 5.6.10.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Sat, 12 Nov 2022 23:58:53 +:


> > No, the best way should be a method to EXCLUDE use of these data
> > structures and functions in a way that could provoke a failure.
> 
> Hum, how do you see this?

The structures are defined in an object environment, and accessed
through object methods. These methods SHOULD make sure the data are not
corrupted when used (of course, they not always do...).

> Re-hum (sorry it happened just after last release), I did try some
> msegui apps with the fpc 3.3.1. with LLVM backend. Here how to
> compile fpc with LLVM backend:
> https://forum.lazarus.freepascal.org/index.php/topic,61069.msg459333.html#msg459333

Oh, Thank you, I did already consider trying something similar, as it
was often stated that LLVM was so fast. This should make it much easier.

> But using LLVM ( who is less tolerant for pointer of pointer )
> reveals some bugs in MSEgui.

That's very good! Finding - and then removing - errors in pointer
constructs makes for more stable software, and at the same time less
open for exploitation.

> Thanks to Jonas Maebe (core dev of FPC and our MSE guardian angel)
> the bug was fixed in last commit:
> https://github.com/mse-org/mseide-msegui/commit/bfb2efea058bb31015764a25c11fd870d701b8b7

I'll get it as soon as possible.

> So maybe your code is no more synchro ( and it is all the goal of
> using git  )

Well, if different people commit different conflicting modifications,
even git cannot do anything else but reject the later one. It just can
give the reason for the conflict to help in resolving it. But of
course, that's "immediate" feedback, and  the one hit by the conflict
can do it.


Vous ecrit au Sun, 13 Nov 2022 01:23:28 +:

> I commited the change from your msegui-shadow. (also added the last
> fixes from Jonas)
> https://github.com/mse-org/mseide-msegui/commit/9db47ee8d576e145cdc2487210b74f115715bde8

Not so fast - did you test it and got it to work for you, hopefully on
Windows and perhaps arm systems, too? As I wrote, I only have Linux
available for now, although I do have a RaspberryPi 3 lying about, that
I'm trying to "heave" to the aarch64 architecture. It still lacks an X
system, though.

> You did lot of work!

Well, not so much. It boils down to a couple compatibility functions
that are quite simple minded, and some hunting for the conditional
compilation sections.

> I did test with ideU and all seems perfect.

Yes, your ideU was my "test bed" also. I hope it uses most of what was
changed, as it's a real BIG project, a lot bigger than Martin's original
IDE.

> Of course with all that fixes the new release will jump to 6.0.0.  

You think this is warranted because of some clean up of conditionals?
The big step had been more appropriately justified by the additions to
the gui code lately, but possibly Jonas Maebe's correction could be
worth it.

...
> Totally out of subject, you are talking about decades of using your
> system. I never understood why "decade" in Englsh is 10 years.

Perhaps that's taken over from german?

> Afaik, "decade" comes from Latin "deca = 10" and "dies = days".

Not for us - in fact, "Dekade" effectively meant any set of ten units
originally, and may have originated through the use of the abacus as a
calculation tool. From there stems the use of the term "Dekade" (in
german) also for a decimal place (e.g. "die Hunderter-Dekade", the
hundreds place). The derivation of the suffix "-de" from "dies" is
completely new to me.

> For example in French, "une decade" is 10 days and "une decenie" is
> 10 years.

Interesting, and new to me, as my knowledge of french is very limited,
in fact I'm probabely a lot better in french grammar than in french
vocabulary...

> So I suppose that your decades was in English, not in French

Well, indeed - I don't usually mix several languages together...
The only exception is the "greeting" phrase of my answers to your
"postings".

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release MSEide+MSEgui 5.6.10.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Sat, 12 Nov 2022 16:23:22 +:

> Hello Sieghard and sorry for the delay.

No problem, no need to hurry.

> About the added "check", It is because I get crash if, using
> mse_dynpo, the application at loading did not correctly load the
> array of lang. It can appear if you load twice the application or if

Yes, I can imagine that this can happen, when and if you don't use the
compatibility functions, but insist to do everything "by hand". The
compatibility functions are explicitely there to resolve problems that
could arise that way, and that's why they do check for correct
initialization internally.
Or, rather, that's what they are supposed to do, anyway. Because of an
experiment, trying to compile your ideU with all variations of using
mse_dynpo, mo files and libfontconfig, I found an omission which might
have provoked a failure. It's in the access properties to the
"extended" and "langnames" arrays. This made an amendment of the
mse_dynpo version of the "msestockobjects" unit neccessary. It's in
the new version of the "mseide-msegui-shadow.zip" file that should be
accessible on my web site.

> the array is corrupted. Also, for example with rpi-aarch64, there was

How could (one of) the arrray(s) become corrupted? This should only be
possible by uncontrolled memory access, through untyped and manipulated
pointers, e.g., or caused by faulty code because of a compiler failure
or a faulty library. This isn't C, where everyone constantly has to
mess with freely accessible pointers and without any type and other
checking. But indeed, I didn't check with arm code (although this
might be an option to explore) and as I don't have good access for
testing there, on Windows, too

BTW, I also included an amendment to the ide code, which uses a chunk
of obsolete definitions that caused compiler errors and failures of
the msespice application from Martin in its original version. I had
to remove some code, and the definition of this data structure that's
obviously nowhere used, any more, at least.

> a bug (fixed now) and because the array of lang was not yet filled,
> when msegui raised a error, that error message crashed the app

And that is correct behaviour of the software! The library routines
were not used as intended, so data structures could end up not or only
partially initialized, what apparently happened.

> > they ALL check for the arrays containig data beyond sc_All,
...
> I agree with you, it not the best way (but now all works ok).

No, the best way should be a method to EXCLUDE use of these data
structures and functions in a way that could provoke a failure.
That's what the objects in object oriented programming are meant for,
I suppose?


Vous ecrit au Sat, 12 Nov 2022 16:35:48 +:

> Sorry to come one more time with the same song.
> But it would be *much* easier for me if you use GitHub site for all
> commits-code-discussion things.

Well may be for you. Not for me though, as I'm not so often on line.
On the other hand, my machine takes care of handling email and news
without need for manual interaction, and it takes almost no time to
handle all of these, so only very little time for aggressors to
intermingle and disturb. A local mail server (exim) and news server
(something like leafnode) do this job in conjunction with a couple
cron jobs to control their external working. I'm very satisfied with
the setup, and that's working for literally decades now.
Yes, but there's still a little catch, as this is basically a mailing
list - which would still be handled by my setup - that I'm reading
through a mailing-list-to-news-group converter server, so I "see" it
like a news group. But that's just a detail of convenience.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release MSEide+MSEgui 5.6.10.

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Mon, 24 Oct 2022 13:59:41 +:

> There is a new release of MSEide+MSEgui: version 5.6.10.
> That stable release has almost fixes of previous release.

Sorry that I reiterate on the new release again.
But I'm a bit puzzled over some modifications that I found and cannot
find any reason for. When I recently scanned the lib/common directory
contents again, I still found the "mse_dynpo" compatibility functions
being completely ignored. And, moreover, you did introduce quite a
number of tests for stock texts that, IMHO, cannot possibly be missing
from the stock data structures, be them the olden static arrays or the
mse_dynpo dynamic ones.
That is, when the latter are accessed through the compatibility
functions, because these DO provide a test whether the arrays have
been initialized, and do it when not.
The only instance that these data structures might NOT be available
I can think of was if the compatibility functions were NOT used for
accessing them, but then they will be missing in full.
And then, what makes me puzzled most about your newly introduced tests
- they ALL check for the arrays containig data beyond sc_All,
disregarding the specific item used in the statement. And I cannot find
any reason WHY this specific item, sc_All, should in any case be so
special that it could create a limit position beyond which the arrays
might not contain any more valid data?
In fact, this should be impossible as long as compiler and the
hardware of the executing machine were intact, as only a memory or
processor, or possibly data transfer, failure could create such a
situation. And why, then, should this specifically occur at the index
value of "sc_All"?
IMHO, you could do away with ALL of these tests when you just use the
compatibility functions provided, what also makes the conditional
compilation for the "mse_dynpo" case obsolete.
In fact, for the previous release, I did just that and never found a
problem, even though I usually compiled all the stuff with "mse_dynpo"
enabled.
I even had put together a collection of my modifications in the file
"mseide-msegui-shadow.zip" on my web site's mse subpage. I'm about to
update this for the new release, but I'm still a bit reluctant to post
it because of the still possible real reason for your newly introduced
tests for partial stock data arrays.
Perhaps you DID run into a problem with these? If so, could you please
give me a hint as to how and why this can happen and how to provoke it,
so it can be repaired?

Thank you, 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
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release of MSEide-MSEgui ?

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Mon, 31 Oct 2022 23:48:54 +:

> > What? You DID WRITE IT YOURSELF that you had created such a"folder"
> 
> Yes, sorry, I did try lot of things before to discover the
> hidden .msetools folder. By default my files manager does not show
> hidden folders.

That's, IMHO, "bad practice" for a developer, especially when he's
also the system administrator. At least for me, I can say that one
definitely NEEDS to have a detailed view of one's system, specifically
the part one "owns dearly".

> So in one of the try I added the parameter -dstocklangs_from_libpath.

And did you also put the files at the implied destination
("/usr/share/locale//LC_MESSAGES/")? It should have
worked then. And the destination is "in plain sight" to everyone.

> And forgot to remove it when I discovered .msetools and add it
> in /home/fred/.msetools. When I removed that parameter, all was ok.

Well, in turmoil, trouble may happen...

> About the use of files out of the all-in-one, yes, I agree with you
> ( but only for hidden-config files, and in the home folder if
> possible.  :-) )

IMFO the user's home directory isn't really a very good location, if
more than one user exists and is meant to use the files. Of course,
this doen't apply for single-user desktop installations, especially
those of the Debian style (that I dislike), where the "main" user is
the system administrator as well - and therewith, if compromised, the
whole system is trashed. (BTW, on my system, I created user accounts
with reduced right to access external ressources, i.e. internet sites,
even for email and news.)

> >  Did you get it to _work_ now? You don't tell.
> 
> Yes, of course and it works great.

Ok, I'm contend if it works - it's work in progress, and rather a
suggestion than a finished implementation. You may fiddle with all
the knobs turnable, e.g. the locations of files, the handling of
preferences or whatever.

Wasn't it a rewarding feature when you can claim that mseide-msegui has
THE superior localization system? Although, I'm afraid, that's still a
long way to go until there...

Best wishes, 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
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release of MSEide-MSEgui ?

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Mon, 31 Oct 2022 08:27:22 +:

> OK, I get it ( had not see the .msetools folder because it was
> hidden).

What? You DID WRITE IT YOURSELF that you had created such a
"folder" (I heartily dislike this denomination), and you presented a
listing of its contents with your last posting!
I thought to remember that it's usually created by mseide-msegui's
installation process, but searching for it, I cannot find it mentioned
anywhere there. So this might have been a wrong reminiscence of mine,
and it should better go somewhere else. But that's not a problem, as
this is STILL an unfinished - and perhaps even unwelcome, project.

> So your idea is to split the po files into a "main_msegui" in
> home/user/.msetools/lang and the "app_lang" po files.

Yes, so to speak. (Although I aimed at .mo files, rather.)

> Yes, of course usefull if you have mainy msegui applications
> installed. I am not sure if I like it inside a hidden folder, I
> prefer open things, but yes, why not.

It pays even if you've only two of them installed. But yes, oh my, I
realize the response: "but memory, especially disk memory, is so cheap
these days"... I'm just not of this crowd.
But it _also_ pays for the application writer - they will no longer
have to create translations for all of the stock items over and over
again, as they can rely on these being pre-translated and ready for
use. (But if need be, they _can_ override them.)
And what about your preference for open things - yes, gladly, what do
you suggest?

> Personnaly I prefer all in one (all files in directory of app) and

This WILL NOT WORK on Windows, AFAIK - they explicitely deny an
application to access data residing in the executable installation
area, I heard. But it was said that there's a sneaky way how the system
fakes such a possibility for unbehaving applications.

> out-of-the-box (no files to be installed outside the folder of app)
> but I know it is not the  accademic Linux way.

No, you know wrong here - it's perfectly possible for an application
_a user installs in his home directory_. It's just not feasible (and
not really useful, nor advisable) to do that for a system wide
installation.
Say, someone wanted to install the "msegit" and "msespice" applications
for all users of his machine. Then, they are to be installed so that
- the application executable should go into "/usr/bin" or
  "/usr/local/bin"
- any application specific libraries go into "/usr/lib" or
  "/usr/local/lib" (doesn't apply for fpc applications)
- and system-wide available application specific data usually reside in
  some application directory within "/usr/share" or "/usr/local/share".
- Additionally, USER SPECIFIC data should go into an application
  dependent directory in his home directory, usually "hidden", if
  created directly, or under ".config", which is often predefined, or
  below a special (hidden) directory created by a "sub system" (like
  msegui, i.e. ".msegui", ".msetools" or some such)

Sometimes, an application will be installed in the "/opt" hierarchy,
under "/opt/", that then contains its
own "bin", "lib" and data subparts, has to manage these itself, and
often provides links to the executable(s) within the common "/usr/bin"
or "/usr/local/bin" directories. E.g. VirtualBox does it that way, or
FreeCAD, if they're not installed by a distribution packet manager.

> But you are right, splitting the po/mo is better way.

Did you get it to _work_ now? You don't tell.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release of MSEide-MSEgui ?

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Sat, 29 Oct 2022 23:40:04 +:

> Here the contents of my /home/fred/.msetools/lang/ folder:
...
> my /home/fred/testfpc/sieghard/podemo_mo4stock/lang/ folder:
...
> And here the result of podemo app:

Interesting...
This looks entirely correct and equivalent to my setup here.
I just unpacked the .zip file into an empty directory again, created a
"units" subdirectory, as advised by the project ptions, and with no
further modifications let the ide compile it. After that, running the
program yields the full list of languages in the selector grid
according to the files found in the ~/.msetools/lang directory, here.
I can even activate an entry and get the translated display.
I suppose you DID use the packaged podemo.prj project file? r did you
created a new project for testing, and forgot to enable the
"mse_dynpo" symbol? If that's missing, the project, interestingly, also
compiles, but then, of course, the language files cannot be found,
because they're not searched in the first place. This DOES give me the
bland "English"-only selector display as well. But, CAN that be?
After all, that is a demonstration of the "dynpo" mechanism, so
building it without that mechanism enabled just plainly deosn't make
any sense at all?
But, on the other hand, if that's not the cause of your problem, I'm at
a loss as to what might go on here, at least for now...

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] New release of MSEide-MSEgui ?

[Sieghard via mseide-msegui-talk]

Hallo Fred,

vous ecrit au Sat, 29 Oct 2022 11:48:53 +:

> Sadly I did not make it work.
> 
> I did a copy of folder /podemo_mo4stock/lang into new hidden
> folder /home/fred/.msetools/. There is now /home/fred/.msetools/lang
> with all the podemo_xx.mo and podemo_xx.po files.

Yes. No, not so. Didn't I tell you to copy the contents of the
directory "/home_user/.msetools/lang" there? ALL of these files have
names of the pattern "msegui_.?o" (? in [m, p]), NOT
"podemo_.*". These are the files containing the central
component of the translation system, (hopefully) ALL of the text items
provided by the msegui libray lang_consts units. They're kept there in
a CENTRAL place to avoid multiple redundant and possibly inconsistent
duplicates.
The latter ones are the APPLICATION SPECIFIC residual language files,
and they DO go with the application into a local "lang" subdirectory
indeed. And if you inspect these files, you will find they only contain
a really small subset of the captions used in the program. (I kept the
".po" files in both parts for easy inspection.)

And that's the purpose of the "trick": NOT to have to repeat ALL the
text items used in an appliction over and over again, but to SEPARATE
them from the "stock" items, which reside in a specific location just
as ONE SINGLE COPY for all the applications using them.

> But at running, only English is loaded.

After you put all of the "msegui_.mo" files into
"/home/fred/.msetools/lang", you should get ALL languages selectable,
and provided you put the file "lang/podemo*" into the "lang"
subdirectory below of where the demo program ("podemo") resides, even
the special items ought to be translated, even
"This is a test of internationalization.", "That is another test."
and "This is the end."
And there's even a switch to allow you to always use the stock items,
even when some of them have been redefined (by accident) in the
application files. It's called "preferStock", default value "false",
and has to be set just before calling the "createnewlang" procedure.
It's not used for the demo, though.
(Also not used for the demo is a quirky conditional define called
"stocklangs_from_libpath" that changes the place for the stock item
subdirectory to the system wide msegui library directory,
"/usr/lib[64]/msegui/lib/common/lang_consts/lang" as an alternative
place. It's meant for discussion whether such a storage place might
be advisable, as a mere user installation probabely would not have
this place at all.)

> May I ask you why not use the /lang folder that is
> in /podemo_mo4stock/lang (lang folder in the same directory as the
> binary-application) ? For testing, it would be much more
> out-of-the-box.

For that, I have to respond: It's in a CENTRAL place because it is
meant to CENTRALIZE often used items to avoid multiple - and then also
possibly inconsistent - versions of these items. Just as dynamic link
libraries do for application programs.

> Also it would be easier to test it in Windows.

Even Windows ought to have a method to put such "library" type things
in a - possibly even user specific - centralized place. In the olden
times, there was the "\Windows" directory, where many programs put
their specific, but application independent, data, sometimes within
special subdirectories, sometimes in subdirectories provided by the
system, and sometimes even directly. I just don't know what the current
practice is under windows and how this could be done there.

I hope you will get it to work with the above information.
You probabely selected the most involved - and likely the most
unfinished - part of all the stuff on my msegui site. But maybe that's
not to bad, since it shows what has to be done to make it easily usable
and what information is neccessary for the prospective user.

Thank you for your interest and the time spent for evaluatiuon, and
I wish you success to get it to work. I hope you can appreciate the
stuff, and perhaps you can make use of it.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk