How to enable delete button while deleting a rule in Application Overlay? - pega

I want to delete a rule from Application Overlay. İ have deleted all AOM ruleset versions that contains the rule to be deleted. Despite this when i open the AO menu to delete the rule, i see the delete button is disabled.
I think this is because pyNewRuleInLP has value and not null. How can I set this property to null to enable the delete button or any other method to do this?

Related

Uncheck a QPushButton with autoExclusive

Ubuntu 22.04, Qt 6.4.0.
I have some QPushButtons that belong to the same parent.
I set all of them with checkable and autoExclusive properties to true.
The doc about the latter states:
If auto-exclusivity is enabled, checkable buttons that belong to the
same parent widget behave as if they were part of the same exclusive
button group. In an exclusive button group, only one button can be
checked at any time;
Emphasis is mine.
From what I understand, they say that only one button "can" be checked. This means that more than one button can never be checked. But it allows to no buttons checked. Otherwise I was expecting something like: "only one button must be checked at any time".
Anyway, my problem is I cannot uncheck a button after it was checked.
It remains checked no matter I click on it.
I also tried programmatically:
ui->myCheckableButton->setChecked(false);
no way.
Disabling the autoExclusive property I can disable them, but of course is not the intended behavior.
What am I missing here?
How to uncheck a button when autoExclusive property is active?
Sadly, you are experiencing the intended behavior of Qt.
The source code for QAbstractButton::setChecked contains lines that makes it clear a button belonging to an exclusive group cannot be unchecked (unless it is the only button in that group).
if (!checked && d->queryCheckedButton() == this) {
// the checked button of an exclusive or autoexclusive group cannot be unchecked
#if QT_CONFIG(buttongroup)
if (d->group ? d->group->d_func()->exclusive : d->autoExclusive)
return;
if (d->group)
d->group->d_func()->detectCheckedButton();
#else
if (d->autoExclusive)
return;
#endif
}
d->queryCheckedButton() returns nullptr if only 1 button belongs to the group. The rest is straight forward:
If Qt was compiled to use button groups and the button group is exclusive, do not uncheck the button (return; instead).
Otherwise, if the button itself is autoexclusive, do not uncheck it.
I checked the exclusive property of QButtonGroup, the description makes the behavior clear:In an exclusive group, the user cannot uncheck the currently checked button by clicking on it; instead, another button in the group must be clicked to set the new checked button for that group..
It is unfortunate the description for QAbstractButton does not contain that sentence too, although I will say it is not incorrect since 0 buttons may initially be checked (then, when 1 is checked, it will never allow to uncheck everything, which is the missing part).
Your modified sentence using must would have a meaning in the lines of:When using the QAbstractButton class, you must make sure not to allow more than 1 button to be checked.There are several instances of sentences built this way and AFAICT, all of them describe things you must do for your implementation to work.
The good news in all of that is that your solution of disabling the autoExclusive property seems no have no impact whatsoever on the signals emitted by the button.You may for instance create a subclass of QPushButton (if that is what you are using), remove the autoExclusive property, first thing in the mousePressEvent and re-enable it last thing in the mouseReleaseEvent.
Alternatively, you can make your button non autoexclusive and connect signals when it is toggled (to true) to unckeck the other buttons.This is probably how I would do it.

Alfresco share customization - adding styles

I would like to change primary button style from Save and Close button to Task completed button.
Where are css classes added to DOM elements?
I know i can edit task-list-toolbar.js to delete alf-primary-button class from Save and close button but how can I add class to Task completed button?
I have checked transitions.ftl and transitions.js but there is nothing.
transitions.ftl and transitions.js , this 2 files are responsible for rendering the buttons.Buttons are rendered dynamically.So you will not find static text inside it.If required You can extend same file for your workflow task and customize it as per your requirement.

Refresh Sitecore after changing icon of Item

I hooked up an extra eventhandler to the Sitecore onItemSaved actions to change the icon of an item in Sitecore. The icon gets changed, but you have to refresh the Sitecore content tree to see that it has changed. Is it possible to programatically make sure the changed icon gets visible to the user instantly in the content tree?
I used:
item.Field["__icon"].Value = "someicon.pgn"
with a Editing.BegintEdit() and a EventDisabler around it.
When you change the Icon of an item in Sitecore itself, the icon gets visible instantly, this is what I would like to see aswell.
Any suggestions?
Thanks!
To refresh the content tree from the code use:
//TODO: set to the appropriate item
String refresh = String.Format("item:refreshchildren(id={0})", currentItem.Parent.ID);
Sitecore.Context.ClientPage.SendMessage(this, refresh);
Remove the EventDisabler, that's likely the issue...
It also disables client events...

Show alert if moving on without saving in Flex?

Functionnaly :
On one of my components of my application, I have an editing/lock system. When a user starts editing, he locks the file so other users cannot edit it.
Problem scenario : When the user activates "edition mode" and leaves screen, I would like to show a alert with two options : save changes, or discard changes.
There are different ways to exit screen :
There is a List on the left side containing other possible editabel data. A click changes the data in my component.
There is a menubar on top leading to other screens.
The edition component is embedded in a Tab navigator. When changing tabs, the alert has to show.
Closing browser.
Do I have to catch all of these events and plug at all those places?
Is there any kind of focusout mecanism?
The answer to the first question is: YES.
You need to watch all possible exit events that could harm the currently edited data.
Well, the problem is now how to manage this properly. Using an MVC framework you would trigger the appropriate commands from your components:
CHANGE_LIST_ITEM (new item)
CHANGE_TAB (new tab)
CHANGE_SCREEN (new screen)
Each command then checks if the currently edited tab has been saved or not. If not, it displays the Alert. Else, if there are no changes, it allows the list, the screen chooser and the tab bar to continue.
So your components (list, screens, tabs) need to implement some kind of rollback or preventDefault mechanism. Generally, changing their state must be allowed by a central validator (in MVC the command).
In the case of the list: I would suggest that the list is not selectable by mouse click but only programmatically. You set a listener on the list item click event. If the command allows setting of a new item it will notify the list. In MVC usually by sending an async message that gets received by the list's mediator. [[And even more correct: The command would set some model properties (e.g. currentListItem) and the model than sends an async message.]]
Edit: For the browser close event, you need to call a JavaScript expert.

Should WP7 edit forms have Save/Cancel buttons or should you use 2 way binding?

This is a question on edit form UI for a WP7 app:
I currently have my edit form fields set to 2-way binding which means that as the user changes them they save on edit and update the UI in the ViewModel (Method 1). So I don't need a Save button and there is no Cancel button (unless you code in logic to store the original state and rollback on cancel).
Method 2 would be to use 1 way binding and UpdateSource on the save button and then you could have a Cancel button which functions like the Back button (goes back without saving).
Method 1 is nice as it handles preservation of state if the app is tombstoned - WP7 will restore the page and your changes will have been saved. The downside is that there is no way for the user to restore it to it's starting state once they make changes. My form is trivial so I do not think this is a problem. The Back button acts as Go Back.
I also do calculations in the setter property in my VM that need to be reflected to the UI (ie you will in Field 1 and Field 2 is double the value (but they can also override it) - I use 2 way binding on Field 1 and update field 1 and 2 on edit. I can't think of a way to do this using explicit updating.
The problem is that I have a Delete button for the record, so when I use Method 1 with no Save and Cancel button the user is likely to click the Delete button as it is the only available option (they need to click on the Back button to go back).
My question is; should a simple form have a Save and Cancel button and commit the data only on Save, or is it ok to use 2 way binding and have no buttons?
Parts of this are mentioned in the UI Design and Interaction Guide page 68.
Changes to Application Settings should be immediately implemented. This
means that a “Done”, “OK”, or other confirming dialog is not needed.
...
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.
As for your situation you will need a confirmation for the delete action (see the ie settings for an example). For your other fields check the guide as other issues are mentioned and you could also see how the built-in settings work.
If it is possible that the user may ever not want to have their entered text changed it'll be easier to have a one-way binding and update the saved value only when the user specifically says to.
Yes, this can make the preservation of entered data slightly harder during tombstoning but means that it's easier fro the user to be able to change their mind.
In your situation, I'd recommend having on screen buttons for Save and Delete (and relying on the hardward back button for cancel).

Resources