OpenXTalk Forums

OXT LIITE does not contain the DataGrid Library?
Stacks that I've made that have DataGrids only partially work without it, for example I can't resize a column. The same stack works fine in LC CE 9.63 and OXT 'Heavy'.

OpenXTalkPaul wrote: ↑Wed Nov 20, 2024 12:53 am Now that I have your serial number I own that too

Haha, no - that's only my Adobe product support ID - which you'd quote with Adobe if you were having issues. Not that they'd support it now of course.

OpenXTalkPaul wrote: ↑Wed Nov 20, 2024 12:58 am OXT LIITE does not contain the DataGrid Library?

It does, but it might just be turned off. (checks to see if it's the default)...
Please check under compatibility, but you can turn it back on - might need a relaunch of the IDE: Testing (another computer), just to make sure it absolutely does toggle correctly This option is there because I was looking to make the IDE as streamlined as possible, and turning these off makes it run on really low-end devices (the Chromebooks I was testing it on, with antix) - but they are all options, as I'm keen to make anything like this a user-customisable option.

Just checked, and although choosing 'reset preferences to default' will show the datagrids as default, I must have left the datagrids disabled in the prefs file that comes along with the install. I'll make sure a prefs file isn't included in future releases, so that none of my presets come through.
This goes back to a time before I could disable the firstrun check in the engine, so I had the installers copy the prefs file. That's no longer needed for Linux and Windows.

Take a fresh version of LCC 9.6.3.

I haven't had a 'fresh' version of LC 963 on any machine for donkey's ages: I have always 'hacked' the MenuBar so I can shove it where I want/

I have, however, just downloaded the 'fresh' version of OXT Lite 109 and installed it.

And can cheerfully say:
- -
It loaded just as easily as the 'stale' version of 109.

The toolbox icon behaves in EXACTLY the same way as before.

richmond62 wrote: ↑Wed Nov 20, 2024 11:35 am The toolbox icon behaves in EXACTLY the same way as before.

Do you mean broken or working? (which 'before' is what I mean) - because it's not just this button. It's all the buttons on macOS when you reposition the window with the titlebar, as discovered. Just I never noticed.
If you drag it around with my grey drag bar on the left, then you don't get the issue of the buttons becoming 'unclickable'. Occasionally I found that dragging around on MacOS will cause that window to jump (for want of a better word) into a new location inexplicably, then the buttons will work again.

The same behaviour is in LCC 9.6.3 if you make the revmenubar into a standard window and move it down so you can drag it around by the window's title bar.

That issue only shows in MacOS. It doesn't do it in Linux or Windows.

It's all the buttons on macOS when you reposition the window with the titlebar

Nuffin works.

Yes, as mentioned - setting that window to a standard window breaks the window as soon as you then drag it via the titlebar. And does the same in LCC on the mac. In Linux and Win (win 7 to 11), there's no such problem.

It makes me think the issue is with some stored rect being passed to the revIDELibrary (something to do with iconising / palletising the stack), but it's so entangled - it's hard to work out if it's a macOS windowing issue or something 'unique' to the mac engine. Certainly those pictures of when I found the bug in LCC 9.6.3 have been viewed over 100 times, so someone is paying attention to them

so someone is paying attention to them

That IS interesting as some people would have us believe that a certain IDE is already moribund and being replaced by some thing else.

Data Grids:

always struck me as great big, clunky things that were a bit of a fudge.

What is interesting is that 'Data Grid 2' was produced in such a way that people using 'Data Grid 1' could NOT continue
using that: a typical example of someone riding roughshod over other people's investment.

richmond62 wrote: ↑Wed Nov 20, 2024 12:28 pm ...some people would have us believe that a certain IDE is already moribund and being replaced by some thing else.

That's an entire whole other topic. Of which I'll hive off into another thread and link to.

richmond62 wrote: ↑Wed Nov 20, 2024 12:31 pm Data Grids:
always struck me as great big, clunky things that were a bit of a fudge.

I can see how they could be handy. Personally, I seldom ever use them. The only time I'd ever make use of them in the IDE is indirectly via the "Project Browser", but I tend to use the "Application Browser" most of the time.
As the "Application Browser" just uses standard fields and buttons, I can say I barely ever use them.

But - that's not to say other people don't of course, so this is why it's an option rather than something I'd ever take out.
Closing all those "RevDataGridLibrary..." stacks in the IDE stops a lot of backwards-and-forwards of messages, frees up memory and speeds things up if you are on low-end hardware. Only slightly mind, but it all helps.

I was surprised, just now, to find the Tools palette overlapping the tools of GIMP, when GIMP was the front-most program:
- -
OXT Lite 1.09

GIMP 2.1.38 revision 1

MacOS 12.7.6

Can you give me some more information to go on, such as:
In preferences > compatibility
Do you have "automatically hide and show IDE windows" turned on or off?

If you have this turned on, I'd ask why - because it's a compatibility setting if you have window focus issues with things like video players and things that draw over the screen (powerpoint is a good example).

This is only a different windows focus mode on MacOS (that's why I put it in compatibility) and it's why it's a preference. You can turn that compatibility mode off if it's working normally.

If that mode is on, did you click the desktop first, then switch to gimp?

Any further relevant information appreciated.

The odd thing is that you can raise any OXT stack/palette, and you can raise any GIMP palette, so that the things are interwoven:
-

Hi,
tried it on a brand new Win11pro machine. "run-install-as-admin.bat" fails (running as admin, for sure):
(DeepL translation:
"Mappings of account names and security IDs were not carried out." and
"0 files processed successfully, a processing error occurred with 1 file.")

Obviously it's the seven instances of: You're sure that you can give users permissions in "program files" on a standard system, one where you don't have messed up permissions & disabled all security before?
Tried it on some other well administrated, known good machines (Win10/11 pro), same result. Trying such icacls in "Program Files", with other targets, all from an elevated prompt, failed reliably.

You might want to change the location of the "changeable files" - those want to be in "user\AppData\Roaming" (where such stuff usually resides), or maybe in "ProgramData". MS:

ProgramData: Unlike the Program Files folder, this folder can be used by applications to store data for standard users, because it does not require elevated permissions.

Best, make an "OpenXTalk" folder in "AppData\Roaming", and throw in all your "moving targets".
And if you're at it, just drop the "User extensions" here, too. Then you can treat this as "user prefs folder" & allow the user to change its location. (There's special cases where you'd like to have it in AppData\Local, ProgramData or elsewhere, but you'd have anything together at a location that works out of the box).

After that, the IDE seems to work at a first glance. I'll try some of my projects with it.

Have fun!

Hi Axwald.
Welcome back!

I've not seen this error before, but can you confirm you are right-clicking the bat install script and running as administrator?
As per these install video demos, I don't get that error on Windows 7 or Windows 11 (or 10 as it happens).
I've not tried in a non UK system, so it could be something to do with that.

User prefs do reside in Appdata, and the program installs to Program files (as many a Windows program does).
However, you can ignore the install bat script if you want. Just look in the installdata folder, Program, and move that OpenXTalk folder wherever you want. It's not picky

The only thing I'd say is AppData roaming profiles won't work if Windows folder redirection scripts are on. In many corporate and education environments (mine included), this is turned on to prevent users installing things to their roaming profiles and running apps indescriminately from online sources. A nightmare for corporate IT. Being in Program Files also prevents guest users without the admin password from tinkering. That was my reasoning. I am following the LCC installer with OXT, which also places the program in Program Files (which also asks for elevated privileges to install because it's writing to a more secure location).

You're sure that you can give users permissions in "program files" on a standard system, one where you don't have messed up permissions & disabled all security before?

I'm not 100% sure I follow you, but this grants read access to the text files in the dictionary for all users. Given that you'd also need either the local admin password or domain admin password to modify this, it's not disabling any security.

For the user extensions, and all the 'moving targets' - these are initially set in the IDE by the engine at startup.
Yes, I could override them to be in the user's Appdata folders, however - again, I haven't changed it from the default - which is to save in the user's Document's folder. The same is true for LCC 9.6.3 on which this is based. I've not had reason to change this.

The reason I'd also not installed in the user's Appdata folders is that there are plenty of malicious tools out there which will allow one user to see another user's appdata folder on the same machine. I do consider this a risk in itself, so that's also why I dislike the use of the appdata folders.

Given that OneDrive is installed as default as part of Windows these days, anything saved in the user's documents folder will follow them around when they move from machine to machine anyway, so I did not see this as a huge issue.

However, if you'd like to make a change to the default preferences for windows - it's in the home stack (add it before line 326 where it says Feel free to test and comment what works for you here.

Edit: I almost forgot - you can change the user extension path to be anything you want, which is recorded for each individual user - so you could point this towards the appdata folder if you really wanted. The setting for that is here:
(without having to edit any script).

If I can help you out with anything, I'll do so - it's nice to see an additional tester as I've not really had any feedback at all on how the Windows version is going for anyone.

richmond62 wrote: ↑Wed Nov 20, 2024 8:17 pm The odd thing is that you can raise any OXT stack/palette, and you can raise any GIMP palette, so that the things are interwoven

That is weird. For a while, Apple used to call this "single application mode" on macOS, where you click one window of a program and all the windows belonging to that program come to the front. Later they seem to have hidden that feature.

I wonder if it's still there, hidden somewhere.
But as I say, if you turn off that window activating setting in compatibility, it'll go back to the old method of window focus.

I'm not sure what version of Gimp you have there. Must be a newer one. I think mine is still on 2.10 and it opens in a fullscreen monolithic window in which all the palettes (if you can call them that) are self contained. Hence no overlapping because there's only one window.

I'm going to go have a dig and see if "single application mode" is still a thing buried in the OS.

Just to show you what I'm on about though, window overlapping between programs happens throughout the OS.
Here, I've got BBEdit open (new text document) and the BBEdit preferences window open. Notice how I've also got a Finder desktop window overlapping between them both? - well, single application mode would prevent that happening (or used to). Edit: it still exists in Catalina at least.
I don't know about any other newer MacOS at the moment (will find out tomorrow).
If you do the following in a terminal: then restart the dock with: When you switch between programs, all application windows belonging to other programs will be hidden, ensuring that only your frontmost program has the windows shown.

You can undo it with: then don't forget to restart the dock again with: (source)

Although there is a 'gotcha' to this. It only seems to work if you are switching between apps with the dock, and NOT if you click between various program windows. It also doesn't work with Cmd + TAB either.

Read my post: version of GIMP is there.

I have turned off single-window mode as I don't like that.

richmond62 wrote: ↑Thu Nov 21, 2024 1:06 am Read my post: version of GIMP is there.

Ah, I see:

GIMP 2.1.38 revision 1

richmond62 wrote: ↑Thu Nov 21, 2024 1:06 am I have turned off single-window mode as I don't like that.

Righto. As you can see, I can do the whole window-overlapping thing with BBEdit and Finder, so completely outside of OXT and the IDE. But anyway, if you turn the option "automatically hide and show IDE windows" [OFF] under compatibility, it'll go back to the original mode.

Perhaps I should rename that button again, - the 2nd line of it in brackets "(only used in Linux and MacOS)"
Perhaps I should change it to "Click an empty area of the desktop to hide IDE windows" (if the stack opens on a mac)...
and if it opens on Linux, change the name to "Try to hide IDE windows when switching programs".
However it's there on the mac because of previous reports of the tools palette (and others) getting in the way when you switch to another program.
Maybe hide the option altogether if you open the stack in Microsoft Windows (because it doesn't do anything there).

With that option turned on, (mac) - click the desktop and it'll hide the IDE windows. If the button is off, it'll use the default behaviour, which (confusingly) doesn't work for everyone on different versions of MacOS.
MacOS 10.9 < 10.14 shows different window overlapping behaviour than MacOS 12 for example. (So a bit like the issue I'm having with various different window managers and desktop sessions in Linux).

But this is why I was keen to make it all a preference setting and not anything set in stone that you can't change.