Pages: « 1 2 3 4 5 6 7 8 9 10 »
 on: February 06, 2019, 05:44:49 PM 
Started by MichaelLohr - Last post by Derek Read
This is what I see when testing with XMAX 13 and your solution, after having moved my %appdata% folder to a Windows share that is mapped to the O: drive (something I already have in place), and making sure there is no SoftQuad folder there (which there isn't by default of course since the "roaming" folder was just created by me and is new). After XMAX created it the first time I removed it again and XMAX had no trouble creating it again, nor writing into it.

In this dialog XMAX is telling us that it is writing out it's minimum set of customization files. I'm not sure if that is normal for your setup. I assume there is no document-level customization simply because this is a stress test. If for whatever reason you cannot work around this problem perhaps providing a full set of customization files will avoid XMAX having to write here (since it can simply load them all from the DTD location).

Here are some guesses:

1. Somehow (without knowing about this issue, nor knowing how to reproduce it) we have altered the way XMAX 13 accesses %appdata% and reads/writes to it. I think that is unlikely as we are using standard Windows APIs for this. It is possible that the Microsoft compiler or code that we used for XMAX 12 is different for 13 (some update has been applied or similar) though I don't think that is the case.

2. Somehow the folder you have pointed %appdata% to on your test system is not functioning the way Windows needs it to, or at least those APIs that we use to read/write files.

3. Something else is interfering with all of this, perhaps some additional 3rd party code is required to reproduce the issue that I do not have. This might be part of your own code, or perhaps it is something entirely separate, such an an anti-virus or other kind of security software, or perhaps the server where these files are stored is somehow behaving oddly when it comes to Windows client machine access.

 on: February 06, 2019, 02:15:46 PM 
Started by MichaelLohr - Last post by Derek Read
I will have a look.

I am testing with XMAX 13 so that might be the difference. You should also try the current release of XMAX on your side to see if that helps. There isn't much point in testing with 12. If there is an issue with that version a fix for it won't be created. If the issue is reproducible in version 13 then (given current development workflow) it would likely be addressed in version 14.

 on: February 06, 2019, 02:29:46 AM 
Started by MichaelLohr - Last post by MichaelLohr
On my regular windows 10 the application crashes with the steps mentioned before so its strange that you could not reproduce it.
It is important to delete the "SoftQuad" folder else it does not occur.

Attached you find a demo application.

The application crashes in MainForm.cs in line 60
_xmControl.Document.RulesChecking = true;
because the "Document" property is null.

Maybe it could work with a mapped drive but the IT department at our customer explicitly does not allow this.

Also I think it would be better to solve the root cause than fixing the symptoms.

Thanks for your help.

 on: February 05, 2019, 04:52:14 PM 
Started by MichaelLohr - Last post by Derek Read
I've followed your instructions, though not on a Terminal Server (I have no access to such a system) on a regular installation of Windows 10 Enterprise instead, and I do not see the issue.

Perhaps if you map the location to a drive letter that will help?

So, instead of having \\data03\USERNAME\roaming\
Map "data03" to a drive letter so that the path is R:\USERNAME\roaming

What kind of error is raised for you when it fails?

 on: February 05, 2019, 04:54:10 AM 
Started by MichaelLohr - Last post by MichaelLohr
Hi Derek,

Thanks for your fast reply.

You can reproduce the problem by the following steps:
* Go to your local %appdata%
* Move the "roaming" directory to a network share by folder properties tab "Pfad" in german.
=> See the attachment for the preceding steps.

* Remove the folder "SoftQuad"
* Start XMAX
=> You get an error while initializing XMAX

Even though the folder "\\data03\temp\mil\roaming\SoftQuad\XMetaL XMAX\12.0" is created by XMAX there seems to be a problem with
user rights in this folder or one of its files.

On our customer's terminalserver each user have its own appdata on a network share like "\\data03\USERNAME\roaming\..." and they are using concurrent licences,
so this is not the problem.

Any ideas about this?

Best regards,

 on: February 04, 2019, 04:19:24 PM 
Started by MichaelLohr - Last post by Derek Read
Each user needs to have their own separate %appdata% location for XMAX (which I think would typically be created for each user/account on a Terminal Server session, or maybe I don't understand how you can configure such a system). If a folder is being shared among users then temp files written there by each copy of XMAX might trigger a race condition and that is not something the software is designed to handle.

If that doesn't sound like the issue you are seeing we will need more information about the setup.
If a Terminal Server is involved and you are not using concurrent licensing then perhaps that is part of the issue?

 on: February 04, 2019, 04:07:53 PM 
Started by pmasal - Last post by Derek Read
This user will need to run the full (EXE) installer package again as the temp files that it unpacks (the MSI and other files) have been deleted from the system after the last time they ran it.

The EXE we provide is a self-extracting archive that unpacks a large number of files to a temp folder (by default the folder you have shown in the screen capture), effectively unpacking what used to be shipped out to users as a CDROM (and something you can still burn onto a CD if you want to back it up and share that around, though not many people have CD drives any longer). Once it has been unpacked the actual installer runs. If those files are deleted then a repair is not possible without re-running the full (EXE) installer package.

 on: February 04, 2019, 02:53:49 PM 
Started by pmasal - Last post by pmasal
Derek's solution (described in his response to my original post) worked perfectly.
Modifying this post because I'm having trouble with the Reply function (site indicates that too many replies have been tried).
Paul M.

One of our users is experiencing variable results from the Insert menu within XMetaL Enterprise with the SDL Tridion Docs authoring bridge (sometimes the Insert menu displays only a few options, sometimes the entire range of options). Since no other users seem to be having the issue, I asked her to first Repair her install, but we're seeing the messages shown in the attached screen shots (I suggested a reboot and then re-run repair - the same thing happened).

The strange thing is that we used an EXE file to install XMetaL 12 and an associated patch (we don't have the requested MSI file). I also checked all local permissions for AppData, the XMetaL Program Files folder, and the associated authoring bridge folders - all are accessible and write-able. Any ideas about what I can do next? Thanks!
Paul M.

 on: February 04, 2019, 07:08:40 AM 
Started by MichaelLohr - Last post by MichaelLohr
Hi Derek,

we are using XMAX12 in a C# application.

One of our customers have a terminal server where the %appdata% folder for every user is mapped to a network share.
On this system it is not possible to initialize the XMAX control.

Do you know this problem and do you have a solution for this?

Best regards,

 on: January 31, 2019, 05:03:54 AM 
Started by PhilB - Last post by TimothyAveri
Hi everyone
Sorry, if this question have already an answer, but i wasnt able to found one...

Is there a way to have, lets say :
- Green Brightness at value 64 for Off Color
- Green Brightness at value 127 for On Color ?

Thanks in advance for your help

Pages: « 1 2 3 4 5 6 7 8 9 10 »