@broadblues
Quote:


Oh, then pgup/pgdown its the same as "space" for go through files.


Quote:

But if i disable directory scaning, disable file-lister, and then dbl-click on test file, probabaly then, pgup/pgdown may work for navigate over document ? (as there will be no other files to navigate over them)

@broadblues

Quote:
I called them. They said that NO email is ever rejected.
EVERY email that reaches the server will be delivered.
Sometimes cropped (if they found a virus), but never completely ignored.

The error is on the end of amigadeveloper.com.

Because i DID get ONE email from Mantis.
That was on the 10th of March 2018, since then something was changed server-side which now prevents the email ever going out from the server.

Who knows? Maybe the server has a blacklist with my email/isp on?

@Raziel

Quote:

Unlikely, blacklists are usually to filter incoming mail not outgoing. I have no access to any mailer logs, or similar, so much as I'd like to, can't help further, sorry for your frustration in this regard.

@broadblues

No problem, thank you for the help so far...

I'll return to check the site as often as possible

@broadblues

Quote:Don't forget that those keys do not necessarily exist on non-english/US keyboards. E.g. on mine I have one key (to the left of the Z key) with both those symbols on, one requiring Shift.

The keys on which you have them are for me - like it seems also for kas1e - the , and . keys.

Best regards,

Niels

@broadblues
Is multiedit have some tooltype mean "Activate main editor area by default" so i not need to hover mouse over it to make it active ? What i mean is that now, when i in shell type let's say "multiedit somefile.txt", then if mouse is not under active typing area, then i can't type anything, as it inactive. I had to move mouse over it, which is not so nice as i don't need mouse there, i need start typing right away from keyboard.

That all of course with disabled file-lister and with disabled scanning of directories.

Maybe there is some way to got this by default without changes from your side ? Like maybe running by default some arexx script which will make that area active for me ?

All tests done on beta texteditor.gadget 53.26, multiedit 1.12.


Also seems found a bug, when i choice after running "scripts/bigger_font" : nothing happens. Then if i choice "Smaller font", then font start to be smaller, that fine, but in shell i have :

32 *-* RELOAD;
+++ Command returned 20

Then, if i choice again "scripts/bigger_font", its instead start to be smaller again, not bigger.

@broadblues

News about item 415 - MultiEdit freeze when opeing new tabs

@all

I don't know if this is a bug per se, but it's awefull nonetheless imo.

With the enhancer package came some stuff for the SDK, including an updated libz.a file which sets the minimum library to z.library 53.6 or higher (which is not available to non-enhancer buyers).

Lately i was alerted that one of my ports stopped working for a non-enhancer amigaos4 user with the error message:
Quote:

I checked the other port and it brought up the same message when using z.library 53.5.

Why is it mandatory to set the libz version to a number higher than the official one available?
That locks out every user who doesn't want to pay for the enhancer stuff.

I don't think i will spend any more time compiling yet another build just to support a vanilla amigaos4.

Is it mandatory to set the zlib version to 53.6?
Can't it stay at 53.5 until the fragmented enhancer stuff becomes finally the "official" amigaos4?

Any ideas how i can rectify that without deinstalling either enhancer or parts of it or providing yet another slightly differing build?

Thank you

@Raziel

I'd consider keeping a boot partition clean of that third-party Enhancer stuff as well as a clean instance of the SDK, activated from that clean boot. Then use that for your development.

You can set up another config/boot partition for using Enhancer and even another SDK instance which you allow Enhancer to add to, for developing stuff which is only guaranteed to work under the Enhancer.

Best regards,

Niels

@nbache

Thank you Niels, but that would be too much hassle.

It'd be easier (and imo fair) for the enhancer guys to revert libz.a to rely on the offical z.library 53.5.

@Raziel

Quote:
It's not mandatory - unless libz.a uses some functionality only available in the new version of z.library. I think Fredrik Wikstrom is the author, so you had better ask him. Perhaps there is a good reason behind his decision.

Quote:
I can assure you that the Enhancer project does not apply a policy to deliberately lock out users who don't own the Enhancer kit. However, certain components may rely on other Enhancer components, either because they provide some necessary functionality, or because A-EON wants to be in full control of its dependencies. Makes sense to me.

@Raziel

It is because newer z.library versions have some new functions that were not in 53.5 and older versions (53.6 added Uncompress2(), 53.8 added InflateReset2() and 53.9 added InflateValidate()).

I made a modified version of the stub library that you can try:
https://www.dropbox.com/s/6z4u4yxihtaeafj/libz.7z?dl=0

This one will only require z.library 53.5 at start, but if a program tries to use one of the functions only available in one of the newer library versions they will fail with the error code Z_VERSION_ERROR unless a new enough version is installed.

@salass00

Thank you very much

I don't know if this thing has already been pointed out but I found a conflict when using x-dock together with Sgrab. Indeed both programs use the combination "Amiga" + "H" to hide/unhide themselves so when I press that combination of keys they both disappear.. Maybe, is it possible to edit the key combination on X-Dock ? (I don't know if Sgrab is still developed and the coder is still around..)

@nubechecorre

The problem is not that they use the same shortcut (they should do that according to the style guide), but that only the program with an active window should react to it.

One of the programs must have a bug which lets it react even though it is inactive.

Best regards,

Niels

Yes, you are right, good point. Is there anyone that can test this behaviour?

@nbache

Quote:
I think you're mistaken on that, Nils. If a commodity has a defined hotkey for showing/hiding its GUI, the actual window state is not relevant. If it were, how could the commodity possibly react to the hotkey in hidden state, i.e. when its window is not active?

@trixie

Well, except we're apparently talking about a menu shortcut, since it was described as Amiga + H.

Menu shortcuts should never pertain to anything but the active window.

Best regards,

Niels

@nubechecorre

I just tested it.

I started X-Dock, and then I started SGrab (from my AmiDock, where it resides).

If the SGrab window is active, Amiga + H hides it and does not affect X-Dock.

If the X-Dock is active, Amiga + H hides it and does not affect SGrab.

IOW, I can't reproduce it.

I may be using a newer (unreleased) X-Dock, though - which version do you have?

Best regards,

Niels

@nbache

Quote:
Ouch, sorry - I thought it was a commodity shortcut you were discussing. My bad, should've read more carefully.