Opened 5 years ago
Last modified 3 years ago
#5650 new defect
OMEdit does not update the cache
| Reported by: | Andrea Bartolini | Owned by: | Adeel Asghar |
|---|---|---|---|
| Priority: | blocker | Milestone: | 1.19.0 |
| Component: | OMEdit | Version: | v1.14.0-dev-nightly |
| Keywords: | Cc: | Francesco Casella |
Description
Working with complex model structure, especially when more tabs are opened, it seems that sometimes OMEdit does not update the cache after modifications made in the text view, either by directly editing the text or, more frequently, after text has been changed using find&replace function.
The effect is that a correct model, for example, fails the check, and to have a correct check it is necessary to close and re-open OMEdit.
Another strange behavior is happened in diagram view: after diagram modification, changing the tab I've obtained a diagram in which all diagrams present in the opened tabs are overlapped...
Unfortunately is not ease to reproduce these malfunctions, especially with small models...
My suggestion is to check the code which provides the cache update...
OMEdit - OpenModelica Connection Editor
Connected to OpenModelica 1.14.0~dev-26749-gf42a582
sysop: Ubuntu 18.04
Change History (8)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
Well, it is still much slower than the OF when moving objects. The effect is more evident when moving whole diagrams, see ticket #5620.
In reality, since when #5620 was opened, NF seems somewhat improved.
However, I'm unable to evaluate the extent of this improvement, because -d=-nfAPI does not change the time needed to move objects, and, for me, the timing purpose does not justify the burden of uninstalling and re-installing OM twice.
comment:3 by , 5 years ago
| Milestone: | 1.14.0 → 1.15.0 |
|---|
Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2.
This issue, previously marked as blocker for 1.14.0, is rescheduled to 1.15.0
comment:4 by , 5 years ago
| Milestone: | 1.15.0 → 1.16.0 |
|---|
Release 1.15.0 was scrapped, because replaceable support eventually turned out to be more easily implemented in 1.16.0. Hence, all 1.15.0 tickets are rescheduled to 1.16.0
I wonder whether a "cache" should be used at all, now that we have a much faster API.