So in my organization's environment i noticed standard change proposal which should move to closed state automatically after being approved are not moving to closed state. In history if you go you can see them moving to closed state from inprogress. But to actually close the record you have to manually do it by Ui Action button for state field. Anyone can explain why oob functionality is not followed. The Br and workflow is correct.Any possible place i should look into
I tried tweaking the Br and using. script tracker to find out how state is changing but i couldn't find anything
Related
We use the TwinCAT 3 Event Logger to track events in our machine. The events are shown to the user with the Event grid control.
Alarms which are raised shows up correctly in the event grid. Every so often it happens that an alarm is cleared, but it never updates in the grid control as cleared. Also when we check the alarm in Visual Studio with the Logged Events window, it doesn't have a cleared date. However, when we check the state of the FB_TcAlarm it has a cleared date or the eConfirmationState is set as NotRequired which means the alarm is currently not in the raised state.
The weird thing is that this doesn't always happen--most of the time the alarms work correctly. Only in rare cases they don't work. Also it is not always the same alarms which malfunction.
Anyone else if suffering from this? Or any idea how to solve/reproduce this?
I have kind of the same problem, but for me it happens when I change something in the code (I have a dynamic array of TcCom objects and FB_Alarms get their own index and register to those TcCom objects with their own name and message) and if I change the name (which is used for doublechecking index) or reset to origin, the old indexes are reset and the old alarms cannot be confirmed away since the original recipient is no longer there. At this point I have to clear logged events through XAE to PLC, stop HMI and delete 2 files in the server.
I know this is not a complete answer, but it helps to know that the HMI has its own eventLogger instance with its own record, PLC has it's own too, and one possible reason for unresponsive alarms is that the recipient FB_TcAlarm has been changed.
The problem seems to have disappeared after we updated to HMI v1.12 and TwinCAT version 4024.10 I believe.
In the unified interface, when I click on the standard button "Reactivate" in the Lead form in order to reopen a qualified Lead, I have a confirmation window that asks what must be the statuscode of the lead, once reopened. In other organizations, I don't have this window, and this difference does not depend on the presence or not of custom statuscodes.
I want to define the statuscode of the reopened lead within a plugin: Is it possible to prevent the display of the confirmation window?
Gotcha! You have to check in your Lead entity Status Reason transitions. If more than one Status Reason defined under Active state, this window will popup.
if this xxxx needs to be activated again, then on Activation, it will ask for the status reason you want that to be on as we have mentioned many status reasons
Read more
You can simply uncheck the Enable Status Reason Transitions so this popup will not appear and you can do this your plugin. But required validations may fail.
When you edit a status reason field the Edit Status Reason Transitions button is in the menu. When you click this button the Status Reason Transitions dialog provides the option to choose Enable Status Reason Transitions. When this option is selected you must define which status reason values are allowed for each status reason. To remove the filtering applied, remove the Enable Status Reason Transitions selection. The transitions you have defined will be kept but not applied.
Reference
I would like our team, to be able, to communicate to others easily, if they have suspended their work with a given reason.
So I would like to have the WIT's with an additional state named "suspended" and an given comment.
What we now would like to achieve, is that the newly added suspended state is set, when we press the suspend work button.
How to add an additional state is clearly documented on the msdn, but is there any possible way, to achieve the above mentioned behaviour, where we do not have to switch to all the associated WIT's and set the state manually?
Your requirement can't be achieved by default. You would need to customize your own add-in in VS.
Can anyone explain what using GCF as a "closed container" actually means?
I understand from this link that you enable this mode of operation using the HandleTopLevelRequests registry key.
I actually stumbled onto this setting as a way to prevent the Developer Tools window from automatically closing upon postbacks/redirects. That default behavior really makes the Network tab almost useless. :(
By setting the HandleTopLevelRequests registry key as described in the link above, the Developer Tools window remains open like I want.
I just don't know if this is a setting I should leave in place because I don't really understand what it's doing.
Or I suppose another way to ask it is, why wouldn't you want the HandleTopLevelRequests setting in place?
**Another registry key named UseChromeNetworking seems to often be used in conjunction with HandleTopLevelRequests. Bonus points for any details on it as well. :)
Any info at all would be appreciated-
I'm currently developing a wp7 app (don't want to tell too much ;), but I'm struggling a little with the user interaction.
The main question, I'm not sure about is: Should I offer an explicit save button in dialogs and use the phone back button as cancel, or should I save implicit the time the user taps the phone back button ...
The more I think about, the more I'm unsure about the best user experience.
I already read the user experience and interaction guide from Microsoft, but there isn't any advice in there about that issue ...
Thx alot for your suggestions.
On page 68 of the Windows Phone 7 UI Design and Interaction Guide it states:
Changes to Application Settings should be immediately implemented. This means that a "Done", "OK", or other confirming dialog is not neededd. In some cases, even though the change has happened immediately, the user may not have feedback that the change has occurred until an ongoing event is completed or a future event occurs. Examples would be joining a secure Wi-Fi network or changing the frequency of alarms.
Keeping Application Settings brief and clear should be a design goal. Complex, multi-page, multi-level Application Settings can frustrate or confuse users into thinking that they have entered another application entirely.
Although the same page also goes on to say:
Immediately implement user-selected Application Settings without a confirming dialog box and provide a feedback method to indicate that the change has occurred.
Avoid creating Application Settings that have more than 2 pages (screens). Settings that require more than a single screen should use overlying half screens to avoid losing context when
the SIP Keyboard is displayed.
If a task cannot be undone, always provide the user with an option to cancel. Text entry is an example. Actions that overwrite or delete data, or are irreversable must have a “Cancel” button.
When using additional screens with commit and cancel buttons, clicking those buttons should perform the associated action and return the user to the main settings screen.
To keep the heading of settings control panels consistent, the heading for the settings page should look as follows:
SETTINGS
<CPL Name/ Application Name>
Applications that fetch data over the network must have an option to disable data usage.
So, I think you only get in to questions over explicit vs. implicit if you have multiple pages for settings, and if you do it sounds like the explicit would be the way to go with sub-pages, but implicit for the initial page.
You should use explicit saving of settings.
However, for data entered it will depend on the application and the data being entered.
It's typcial to include a save button (or equivalent) otherwise there's (probably) no way for the user to cancel out of a partially entered form. This can also cause issues if there are validation issues which would prevent the saving of the partially entered data.
It depends on the app though. There is no universal rule for this.