We're running a project in which react-hook-form has worked fine, however the dirtying doesn't function, and never has. It should activate once the useForm has gotten default values after which the user changes some of the fields.
What are some of the situations where the library might have the problem of not behaving correctly with dirtying?
Related
I have an application in which one opens many windows. I added copy/paste, using XA_PRIMARY.
That works fine within my application. It also works fine when copying from other applications (pluma, FireFox, mate terminal) into a window of my application.
When I call XSetSelectionOwner(), with time stamp etc as explained in the documentation, server acknowledges new owner. That is, XGetSelectionOwner() returns the owner I just set.
However, when copying from my app to other applications I do not receive SelectionRequest.
From what I see, server only sets the owner for the Display used in the call XSetSelectionOwner().
Is this how it is supposed to work? Then, is there something else to do so server sets owner for all apps?
Given the behavior of the Server, I had to assume that other clients are not making their request for "PRIMARY". So, I added "CLIPBOARD", and now everything is working great.
The documentation appears to say that every client will use PRIMARY. Further reading seems to indicate that there is a difference between making a "selection", and "copying text". They seem to skirt this as a useful feature. I see nothing but confusion. Anyway, there really was no bug in my app. I think documentation should have a line saying: You must implement both, PRIMARY and CLIPBOARD. That was the problem.
Having an entity with a date field inserted/updated via a SAPUI5 dialog. After some consecutive updates (changes on the date via the datepicker) on the same record, I experience this weird error. I say weird because I don't have this kind of check inside my update entity. In fact the update entity method does nothing more than performing a couple of simple checks in other fields and eventually inserting the record, no calls to BAPIs, standard SAP function modules or anything. Also weird the fact that it doesn't happen always. Spent half the day repeating the same motif, just consecutive updates with debug, sometimes it happens, sometimes not. No exception occurs in my method, error comes from standard SAP after the end of get_entityset which follows the update. If helpful, I attach a snapshot of the batch operations involved.
Batch operations table
And it gets better! After the application crashes, never opens again, it actually produces during the load of the initial worklist (get_entityset method) a variation of the aforementioned error (Message E FK 080 cannot be processed in plugin mode HTTPS). Application stops crashing...as soon as I delete the record from the database.
Record looks just fine in SE16N and gateway client works fine when I test the get_entityset method. Cleared all cache in the system (used this: https://blogs.sap.com/2016/03/02/cache-maintenance-in-fiori/), cleared even the browser cache (yeah, I know that doesn't make sense) but problem persists. I use model.submitChanges to update, no change groups involved.
Does this ring any bells to anyone?
Best regards
Greg
This is a bit of a crazy one. I have an IOS app that saves an object to Parse.com's datastore. Until a couple of days ago everything worked well. Now, suddenly, the object is not going into the database. I would put the code here but it doesn't seem to be the issue, as it gets even more bizarre:
When I go directly to the data browser and insert a row manually, it shows up right there.
But when I refresh the data browser -- the object is gone.
Looking at the forums here's some more data:
When I save from the app, I have an existing current user.
The object itself exists.
The permissions on my class are all "Public."
The app codes are correct (I'm able to read from the database.)
I'm even seeing the saveInTheBackground success block getting called, and printing out the object it has a valid object id!!!
But then it goes pooooooffff and is gone.
Any idea what's happening?
EDIT: I added a different class with the exact same columns, changed the appropriate fields in the app, and now everything works. But this is obviously alarming, that a class stops saving objects all of a sudden. Any idea why?
I've noticed a problem with nested forms and i'm not sure how to solve it. My forms are working fine normally, this isn't really a question about how to get them to work. This question is more of a 'what should I do in this scenario'.
When I use a nested form via fields_for it works great. When I add in the javascript to be able to add and remove fields everything works great. I can add, save, remove, save, no problems. However If you edit an object with a nested form then delete one of the nested objects (via sending the {'_delete' => true} parameter with the object), then you use the back button and save that form again without deleting the same fields you will get an error.
Your browser caches the field that should no longer be there, then Rails tries to find the old object via the 'id' element in the hash and it fails, rightfully so. Is there anyway I can prevent this? Do I need to just manually inspect the hash to make sure the element is still there? Is there some way I can force a browser refresh or something? Thanks for your time.
Yes and no. Your application has very little control over browser behavior. If the browser sends information to your application that no longer has relevance the best you can do server-side is validate against that and present the user with a clean error message (or silently drop the invalid record ids, but that could be very confusing to the user.)
The alternative is to try and get the browser to stop caching the page in question, you may have seen this before in bank or other sensitive applications where you hit your back button and you're presented with a warning "this page has expired". You could use meta tags or http headers to set the expiry date in the past or use pragma: no-cache.
https://gist.github.com/773373
Non relevant fields are initialized on page refresh.
Steps to reproduce
Access the page. Notice the two alerts. "init - uncheck" and "enabled - uncheck".
Select the check box. Check control is initialized. Two alerts again. This control was not relevant previously.
Refresh the page (I am using firefox). Notice the non-relevant control is initialized but the relevant control is not. You can tell from the alerts.
Interestingly the right component is shown but xforms-enabled is called on the wrong component.
Getting those 2 alerts for the non-relevant control on page refresh is normal. However, after those, you should also get alerts for the newly relevant control. I created a bug for this, and will update this response when the issue is fixed.
When you do a reload (ctrl-r) on Firefox, the HTML is in its initial state, as it was the first time the page was loaded. However, since Firefox resets the form fields to their value before the reload, we can detect with JavaScript that a reload happened, and the browser can ask the server "please tell me everything I need to do on the initial HTML to put it back to state X". The server resends all the events it sent when you clicked on the checkbox, except the <xxf:script>, which is responsible for your script running, hence the behavior you observe.
We did some brainstorming on this issue, and described a solution, which at this point still need to implement.