Pages: « 1 2 3 4 5 6 7 8 9 10 »
 31 
 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.

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

 33 
 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,
Michael







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

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

 36 
 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 12.0.0.081 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.
McAfee

 37 
 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,
Michael



 38 
 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

 39 
 on: January 30, 2019, 06:26:32 PM 
Started by A S - Last post by Derek Read
I recall this bug. It was introduced sometime between version 8 (?) and 10 and was corrected sometime between version 10 and 13, though I'm not sure exactly when. I think it was introduced with version 8 because of a conflict with the new feature added that slides windows out of the way ("pin" and "auto hide").

I've tested the behaviour in 13 (current release) and see the expected behaviour.

A value entered in the Attribute Inspector should be set when you perform the following actions:
- move to a different attribute (in the Attribute Inspector) for the same element using the mouse or tab key
- press enter
- put focus back into the same document using the mouse
- put focus into a different document using the mouse

Pressing the Esc key will return to the document without setting the attribute.

Note that this applies to setting values directly in the Attribute Inspector only. If an attribute is set in a form (even one launched from the Attribute Inspector) the logic for how attributes are set is contained entirely within the form and may vary depending on the customization and how the form was designed to function.

 40 
 on: January 30, 2019, 06:05:21 PM 
Started by A S - Last post by A S
In XMetaL 10 Author, when a user is working on a topic in Tags On view and they enter an attribute value using the Attribute Inspector, the value is not saved unless the user clicks in a different attribute field before leaving the Attribute Inspector. If a user enters an attribute value in the Attribute Inspector and then clicks in the main window, the att inspector closes without saving the new att value. As a result, users assume the attribute value has been saved, when it has actually been deleted. Requiring users to click in a different, blank attribute field in order to save an entered attribute value is inconvenient.

Steps to reproduce:
1. Open a topic in XMetaL 10, in Tags On view.
2. Add a new tag pair and click after the opening tag.
3. Open the Attribute Inspector.
4. Type a value in one of the attribute fields and click in the topic pane.
The Attribute Inspector closes.
5. Open the Attribute Inspector and verify that the value entered in step 4 is not present.
6. Type a value in one of the attribute fields and click in a different, blank attribute field.
7. Click in the topic pane.
The Attribute inspector closes.
8.  Open the Attribute Inspector and verify that the value entered in step 6 is present.

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