Hallo Zusammen,
wäre es nicht toll wenn man sich anschauen könnte welche Änderungen noch nicht gespeichert sind?
Ich stelle mir das so vor das ein Befehl unsaved - die DEFs ausspukt die verändert wurden aber noch nicht gespeichert sind...
Dazu müsste fhem die gespeicherte Konfiguration komplett neu einlesen und mit der gesamten laufenden Konfiguration vergleichen. Fhem selbst weiss nicht, was noch nicht gesichert wurde.
das wäre aber kein besonders eleganter ansatz.
wenn man das feature in fhem einbauen würde wäre ein timestamp der beim define oder modify im $hash gesetzt wird und ein timestamp der bei save gesetzt und die man vergleichen kann glaube ich der bessere weg. oder sogar nur ein flag das bei save zurück gesetzt wird. das könnte man sogar in der devspec beim list verwenden.
du kannst das aber einfachen mit zwei notifys selber bauen:
eines auf global:(DEFINED|MODIFIED) in dem du mit setreading $NAME unsaved changed ein 'unsaved' reading im betreffenden device erzeugst und ein zweites auf global:(SAVE|INITIALIZED|REREADCFG|SHUTDOWN) in dem du all diese unsaved readings mit deletereading .* unsaved wieder löschst.
das erste notify kannst du auch noch um ATTR|DELETEATTR erweitern dann bekommst du auch attribut änderungen mit.
mit einem list .* unsaved bekommst du alle nicht gespeicherten devices mit dem timestamp der letzten änderung.
gruss
andre
Und wohin speicherst Du die Timestamps bei gelöschten Devices?
In der configDB ist eine diff-Funktion bereits länger enthalten, ich arbeite gerade an einer Erweiterung, damit man mit "configdb diff all current" genau die nicht gespeicherten Änderungen sehen kann.
für gelöschte devices kann man ein drittes notify auf global::DELETED verwenden das die device in einen dummy steckt.
sich mit einem diff device basiert beliebige änderungen zwischen beliebigen versionsständen ausgeben zu lassen wäre in der tat nett.
aber warum gibst du current an? wäre nicht lastSaved oder ein zeitpunkt besser um die aktuelle mit einer vorigen version zu vergleichen?
Zitat von: justme1968 am 17 Januar 2015, 16:51:22
aber warum gibst du current an?
Weil ich ein Unterscheidungskriterium brauche. Und weil Du die configDB und ihre Möglichkeiten nicht kennst.
Die allgemeine Syntax des bereits existierenden Befehles lautet:
configdb diff <device> <version>Damit kann man für ein beliebiges Device die Konfigurationseinträge zwischen der aktuellen (gespeicherten) und einer vorherigen (gespeicherten) Version vergleichen.
compare device: wz_Harmony in current version 0 (left) to version: 1 (right)
+--+--------------------------------------------------------------------+--+--------------------------------------------------------------------+
| 1|define wz_Harmony harmony 192.168.123.188 | 1|define wz_Harmony harmony 192.168.123.188 |
| 2|attr wz_Harmony userattr Beleuchtung Beleuchtung_map structexclude | 2|attr wz_Harmony userattr Beleuchtung Beleuchtung_map structexclude |
| 3|attr wz_Harmony Beleuchtung allLights | 3|attr wz_Harmony Beleuchtung allLights |
| | * 4|attr wz_Harmony event-on-change-reading .* *
| 4|attr wz_Harmony group 00 Harmony | 5|attr wz_Harmony group 00 Harmony |
| 5|attr wz_Harmony room 60 Fernbedienung | 6|attr wz_Harmony room 60 Fernbedienung |
+--+--------------------------------------------------------------------+--+--------------------------------------------------------------------+
Im Beispiel wurde das Attribut event-on-change-reading in der aktuellen Version gelöscht.
Das "current" würde dann (neu) kennzeichnen, dass mit der im Speicher befindlichen Version verglichen werden soll.
Ich kenne das unsaved feature von unseren Maschinen, und nutze es sehr oft.
Den Ansatz mit den notifys finde ich schonmal gut, das es mit config.db sogar noch einfacher sein dürfte klingt logisch.
Ich stehe einfach oft vor der frage ob ich auch alles was ich speichern wollte gespeichert habe bevor ich ein Shutdown & Restart absetze.
Wenn es unsave gäbe müsste es aber auch ein "rückgängig" geben damit man in der Hand hat was man speichert..
Es würde ja prinzipiell schon reichen, wenn nach irgendeiner Änderung der Text "Save config" im Frontend einfach in rot erscheinen würde.
Den Vorschlag hatte ich vor langer Zeit schonmal hier im Forum gebracht - aber es gab keine Reaktion darauf.
Zitat von: der-Lolo am 17 Januar 2015, 17:01:06
Wenn es unsave gäbe müsste es aber auch ein "rückgängig" geben
nennt sich "configdb recover <desiredVersion>" 8)
Ja, die Vorzüge von cofing.cb würde ich gerne nutzen - aber vor dem einrichten und dem gebastelt bei nicht Funktion habe ich ein bisschen sorge...
Mit solchen unbegründeten Vorurteilen solltest Du auch besser die Finger von der configDB lassen.
Davor muss man keine Sorgen haben. Sorgen müssen nur die Leute haben, die meinen, sie wären schlauer als ihre Datenbank selbst. Und Leute, die mit der Datenbank Dinge tun wollen, für die die Datenbank nicht vorgesehen ist.
Die meisten "Probleme" mit der configDB, über die irgendwelche User hier im Forum klagen, sind dem zwanghaften Trieb zuzuschreiben, irgendwann selbst mit irgendwelchen Tools in der Datenbank rumpfuschen zu wollen - wozu es keine Notwendigkeit gibt. Ich habe eine ganze Menge fhem-Installationen mit configDB laufen, irgendeinen Grund, in der Datenbank selbst irgendwas ändern zu wollen, gab es hier noch nie.
Die zweithäufigste Fehlerursache ist fehlendes Linux-Grundwissen (insbesondere was Rechte betrifft) obwohl man auch davon eigentlich gar nicht viel braucht, um die configDB einzurichten.
"configdb diff all current" liefert:
compare device: all in current version 0 (left) to version: -1 (right)
+-----+-----------------------------------------------------------------------------------+-----+-----------------------------------------------------------------------------------+
| 142|define bd_RT_Weather CUL_HM 21C0B801 | 142|define bd_RT_Weather CUL_HM 21C0B801 |
| 143|define bd_RT_WindowRec CUL_HM 21C0B803 | 143|define bd_RT_WindowRec CUL_HM 21C0B803 |
| 144|define bd_RT_remote CUL_HM 21C0B806 | 144|define bd_RT_remote CUL_HM 21C0B806 |
| | * 145|define blubberTest dummy *
| 145|define btLumia630_bt PRESENCE local-bluetooth B8:4F:D5:D4:27:3A | 146|define btLumia630_bt PRESENCE local-bluetooth B8:4F:D5:D4:27:3A |
| 146|define cal_Command notify Kalender_Command:modeStarted.* { calCommand("$EVENT") } | 147|define cal_Command notify Kalender_Command:modeStarted.* { calCommand("$EVENT") } |
| 147|define calendar RSS png 192.168.123.241 ./FHEM/calendar.layout | 148|define calendar RSS png 192.168.123.241 ./FHEM/calendar.layout |
+-----+-----------------------------------------------------------------------------------+-----+-----------------------------------------------------------------------------------+
| 150|define cubie_dev PRESENCE lan-ping 192.168.123.242 60 60 | 151|define cubie_dev PRESENCE lan-ping 192.168.123.242 60 60 |
| 151|define dew_all dewpoint dewpoint out_Balkon | 152|define dew_all dewpoint dewpoint out_Balkon |
| 152|define dew_state dewpoint dewpoint out_Balkon T H D | 153|define dew_state dewpoint dewpoint out_Balkon T H D |
* 153|define difftest dummy * | |
| 154|define esszimmer RSS png 192.168.123.241 ./FHEM/esszimmer.layout | 154|define esszimmer RSS png 192.168.123.241 ./FHEM/esszimmer.layout |
| 155|define ez_Licht_Tisch CUL_HM 26C5FE02 | 155|define ez_Licht_Tisch CUL_HM 26C5FE02 |
| 156|define ez_TV CUL_HM 24E6BF | 156|define ez_TV CUL_HM 24E6BF |
+-----+-----------------------------------------------------------------------------------+-----+-----------------------------------------------------------------------------------+
| 1417|attr n_sz3l room 60 Fernbedienung | 1417|attr n_sz3l room 60 Fernbedienung |
| 1418|attr n_sz3s group HMFB03 | 1418|attr n_sz3s group HMFB03 |
| 1419|attr n_sz3s room 60 Fernbedienung | 1419|attr n_sz3s room 60 Fernbedienung |
* 1420|attr n_tts1 disable 0 * 1420|attr n_tts1 disable 1 *
| 1421|attr n_wz1l group HMFB05 | 1421|attr n_wz1l group HMFB05 |
| 1422|attr n_wz1l room 60 Fernbedienung | 1422|attr n_wz1l room 60 Fernbedienung |
| 1423|attr n_wz1l showtime 1 | 1423|attr n_wz1l showtime 1 |
+-----+-----------------------------------------------------------------------------------+-----+-----------------------------------------------------------------------------------+
| 1908|attr wztablet verbose 5 | 1908|attr wztablet verbose 5 |
| 1909|attr zoom group RSS fh.j65.de | 1909|attr zoom group RSS fh.j65.de |
| 1910|attr zoom room 97 RSS | 1910|attr zoom room 97 RSS |
* 1911|#created Sat Jan 17 17:05:28 2015 * 1911|#created Sat Jan 17 17:47:08 2015 *
+-----+-----------------------------------------------------------------------------------+-----+-----------------------------------------------------------------------------------+
Die nicht gesicherte (laufende) Konfiguration befindet sich rechts in der Tabelle.
Gegenüber der gespeicherten Version gab es folgende Änderungen:
- das device blubberTest wurde neu angelegt
- das device difftest wurde gelöscht
- im device n_tts1 wurde das attribut disable von 0 auf 1 geändert
- im letzten diff-Block steht in der letzten Zeile immer der Timestamp der verglichenen Versionen
Zitat von: der-Lolo am 17 Januar 2015, 14:14:09
wäre es nicht toll wenn man sich anschauen könnte welche Änderungen noch nicht gespeichert sind?
übrigens: Danke für den Vorschlag :)
Ich habe keine Vorurteile bzgl. config.db - ich habe mich nur mittlerweile daran gewöhnt die fhem.cfg per Oberfläche zu bearbeiten, wenn man das beherzigt gibt es ja auch keine kaum Probleme mit der fhem.cfg.
Zitat von: der-Lolo am 17 Januar 2015, 19:22:20
Ich habe keine Vorurteile bzgl. config.db
das liest sich für mich hier aber völlig anders:
Zitataber vor dem einrichten und dem gebastelt bei nicht Funktion
Man kann (und muss!) auch bei der configDB alles über die fhem-Oberfläche bearbeiten. Wobei Du da eigentlich keinerlei Unterschiede feststellen wirst, da die configDB komplett transparent eingebunden ist.
ich hab eben hier: http://forum.fhem.de/index.php/topic,31293.msg247380.html#msg247380 (http://forum.fhem.de/index.php/topic,31293.msg247380.html#msg247380) einen patch gepostet mit dem der 'Save Config' link rot wird sobald es nicht gespeicherte änderungen gibt.
hihihi...
Damit kriegt der Threadersteller aber immer noch nicht raus, welche Änderungen noch nicht gespeichert sind.
simmt.
aber der zweistufige ansatz zuerst auf einen blick zusehen das noch nicht gespeichert ist und dann nachschauen zu können was ist ja an sich nicht verkehrt.
und das mit den notifys von oben geht ja trozdem :)
Die beschriebene Lösung für configDB Anwender kommt morgen oder übermorgen per Update, ich mache nur noch ein paar Tests :)
Ok - ich sag es mal so, ich verfolgte damals den thread aus dem config.db entstanden bzw. wo über solche möglichkeiten diskutiert wurde.
Config db geht aus dem thread klar als best way heraus. Zu diesem Zeitpunkt war ich aber bereits auf den Cubietruck am umziehen. Config Db werde ich in jedem fall mal "probieren" wenn ich ein neues System aufsetze.
Du kannst auch auf einem laufenden System jederzeit umsteigen - in beide Richtungen. (ist aber hier offtopic)
Ich habe gerade das fhem hier auf dem Macbook von fhem.cfg nach configDB migriert, dauert unter einer Minute :)
Zitat von: justme1968 am 17 Januar 2015, 20:34:15
ich hab eben hier:
einen patch gepostet mit dem der 'Save Config' link rot wird sobald es nicht gespeicherte änderungen gibt.
Doofe Frage: Soll denn die rote Anzeige mit den von Rudi gestern noch eingebauten Änderungen nach dem heutigen Update schon funktionieren? Bei mir tut sich da nix in Sachen Farbgebung.
im default style geht das aktualisieren wenn man auf dem terminal etwas ändert aber beim raum wechseln geht das einfärben noch nicht weil der style in den css files noch fehlt.
ah ok, dann muss ich mir ja keine Gedanken machen, dass ich noch keine rote Farbe zu sehen bekomme :)
mit der aktuellen version sollte wieder alles gehen.
wenn nicht schau bitte mal auf die js console.
Save Config ist bei mir so gut wie immer rot :(
Wenn ich "Save Config" ausführe wird der Menue Punkt kurz schwarz, aber nach kurzer Zeit sofort wieder rot. Ich habe definitiv keine Configänderung durchgeführt
Viele Grüße
Das kommt daher, dass auch Änderungen, die durch eine Konfiguration im Hintergrund durchgeführt werden (ein at wird durch ein notify erstellt, disable 1 etc, watchdog trigger) dazu führen, dass die CSS-Klasse gesetzt wird.
Zitat von: karl0123 am 19 Januar 2015, 12:44:56
Das kommt daher, dass auch Änderungen, die durch eine Konfiguration im Hintergrund durchgeführt werden (ein at wird durch ein notify erstellt, disable 1 etc, watchdog trigger) dazu führen, dass die CSS-Klasse gesetzt wird.
aber damit geht die angestrebte Wirkung verloren, schade :(
Positiv, durch den roten Menuepunkt wird man häufiger mal zum Save angeregt :)
der trigger auf einen watchdog sollte keinen einfluss haben.
man könnte alle at die nur ein mal ausgeführt werden ausnehmen. wie ist die meinung dazu?
statt so einem at kann man oft auch ein fhem sleep verwenden. das macht den button auch nicht rot.
disable 1 macht den text rot. das finde ich aber sinnvoll.
gruss
andre
Zitat von: justme1968 am 19 Januar 2015, 12:58:10
der trigger auf einen watchdog sollte keinen einfluss haben.
man könnte alle at die nur ein mal ausgeführt werden ausnehmen. wie ist die meinung dazu?
statt so einem at kann man oft auch ein fhem sleep verwenden. das macht den button auch nicht rot.
disable 1 macht den text rot. das finde ich aber sinnvoll.
gruss
andre
Ansatz finde ich gut, die temporären "at" kommen vermutlich eh nur von FHEM selbst, wie z.B. bei follow-on-for-timer
Bei mir wird Save config nach wie vor überhaupt nicht rot. (Google Chrome)
Und in der JS-Console sind keine Auffälligkeiten erkennbar.
welchen style verwendest du ?
ich habe gerade gesehen das rudis version noch nicht mit allen styles funktioniert. default sollte auf jeden fall gehen. dark geht noch nicht.
edit: falls es dark ist kann im darkstyle.css die zeile 24 vermutlich komplett entfallen. dann geht es auch mit dark.
Zitat von: justme1968 am 19 Januar 2015, 13:36:11
edit: falls es dark ist
Es ist dark...
Zitat von: justme1968 am 19 Januar 2015, 13:36:11
kann im darkstyle.css die zeile 24 vermutlich komplett entfallen. dann geht es auch mit dark.
Nein, es geht auch dann nicht. "Save config" ist dann fast immer rot. Sowohl direkt nach dem Aufruf des Webfrontends als auch beim Raumwechsel.
die gleichen Fehler treten hier übrigens auch im default-Style auf.
hmmm. default geht bei mir out of the box und dark nach entfernen der zeile. sowohl mit safari als auch mit chrome.
geht es noch bei jemandem ausser mir ?
bei mir funktioniert es auch, ich verwende allerdings den ios6-Style.
Bei mir ist "save" immer ort mit dem dark style :-\
Bei mir ist "save config " auch immer rot mit dem dark style
Ich habe nun auch endlich ein update gemacht - sorry Andre, mir war nicht klar das ich eine Baustelle dieser große öffne.
Gelegentlich funktioniert es - so wie ich das sehe gibt es aber ein paar Devices die nach einem set on oder set off "save config" rot einfärben. Reproduzierbar ist das bei mir bei HM-Messsteckdosen - und dem LGTV.
Mein Ziel ist auch leider noch nicht erreicht, es wäre halt auch toll wenn man sehen könnte welche Änderungen gespeichert werden.
Wenn ich nur nicht so einen Respekt hätte mit meinem Produktivsystem auf config.db umzusteigen...
ZitatWenn ich nur nicht so einen Respekt hätte mit meinem Produktivsystem auf config.db umzusteigen...
Trau dich! Es tut nicht weh! ;)
Moin,
ich verwende hier den Default Style und IE11 und habe ständig "save config" in Rot, da hilft auch kein drücken auf Save, kurz danach ist es wieder Rot.
Kann man diese Funktion nicht einfach canceln, vorher war doch alles im Lot....
soll ja gerne wieder rein wenn es stabil ist.. aber so......
ner.. d.. e.. bi..... :-)
mfg karack
Die Funktion ist einfach ein furchtbarer Krampf. Aber solange (Rudi || Andre) der Meinung sind, das sei ok, wird sich vermutlich nicht ändern. Wen interessieren schon die Anwender...
:-\
das die anwender nicht interessieren ist eine unterstellung und stimmt nicht.
das die funktion gleich eingecheckt wurde ist etwas unglücklich. ich denke etwas mehr erfahrung wie genau man auf welche änderungen reagiert hätte durchaus geholfen.
es gibt auch zumindest schon zwei vorschläge wie man die 'falsch' positiven so vermindert das es sinnvoll und wie gedacht benutzbar ist.
ich denke das feature an sich ist so nützlich das ein einfach aufgeben und rausschmeissen schade wäre.
gruss
andre
nur zu sagen bei mir geht nichts (oder meckern und javascript zu hassen) ist übrigens genau so wenig produktiv wie zu sagen bei mir geht alles.
Zitat von: justme1968 am 23 Januar 2015, 21:04:39
das die anwender nicht interessieren ist eine unterstellung und stimmt nicht.
Das ist keine Unterstellung, sondern eine Erfahrung, die sich hier im Forum anhand unzähliger Beispiele problemlos belegen lässt.
Vielleicht solltest Du Deine genialen Ideen einfach testen BEVOR Du sie an die große Glocke hängst.
Ausserdem habe ich nirgends behauptet, dass das Feature an sich nicht nützlich sei - im Gegenteil hatte ich das Feature schon vor vielen Monaten vorgeschlagen. Aber es sollte eben so umgesetzt werden, dass es auch zuverlässig funktioniert. Und da das Fehlverhalten hier schon mit der "originalen" fhem.cfg auftritt, kann es nicht an meiner Konfiguration liegen. Insofern sind die Leute für die Fehlerbehebung verantwortlich, die den Mist verbockt haben.
Und nicht ich als Anwender.
Zitat von: karack am 23 Januar 2015, 20:02:13
Kann man diese Funktion nicht einfach canceln, vorher war doch alles im Lot....
was spricht gegen ein einfaches:
/* .changed a, .changed { color:red!important; }*/
Grüße,
Oli
War mal wieder Zuhause am Rechner, d nutze ich den iOS7 Style, das ist es auch immer rot.
Grundsätzlich finde ich die Funktion super.
Oft ändere ich was, speichere, ändere, usw. und dann denke ich mir, hab ich jetzt gespeichert, oder nicht.
Meist speicher ich dann nochmal.
naja, nur die rote anzeige war eigentlich nicht mein gewünschtes Ziel - ich glaube mittlerweile das die funktion nur dann sinn macht wenn man auch gezeigt bekommt was wo verändert wurde vor dem letztem speichern...
@der-Lolo: habe einige Aenderungen eingebaut, bitte testen.
Hallo Rudi,
ich habe gerade ein update gemacht gefolgt von einem shutdown & erstarrt -
danach habe ich die HM-Energiemesssteckdose und das LGTV Modul getestet.
bzw. etwas geschaltet, der Effekt bleibt gleich - hätte ich aus dem SVN aushecken müssen?
Welche Dateien soll ich holen und testen?
update funktioniert ab morgen.
SVN checkst du am besten komplett aus.
da muss ich nochmal fragen - update force bringt es nicht, oder?
Alle Dateien einzeln holen und rüberkopieren?
Nein, update force kann auch nicht in die Zukunft schauen.
Also entweder bis morgen warten, mit fhem.cfg.demo testen oder einzeln kopieren.
Danke, ich warte bis morgen und melde mich hier.
Guten Morgen Rudi,
Danke für das update! Das gefällt mir gut - nur das ? ist mMn nicht gerade ein geeigneter "Klickpunkt" was besseres fällt mir aber auch nicht ein. Bei unseren Maschinen ist es lustigerweise ein ! als Icon.
Das Popup zeigt nun schön welche Änderungen nicht gespeichert sind - und hierbei fällt mir auf das ich mich entschuldigen muss, mit den beiden Schaltern für die Energiemesssteckdose und im LGTV löse ich weitere Aktionen aus die aktiv Attribute verändern und oder einen Pageswap auslösen. Die "unsaved" Funktion erkennt also alles richtig.
ZitatLast 10 structural changes:
attr pr_soBuero disable 0
attr pr_soBuero disable 1
define reset_pageswap at +00:00:01 set Dum_page...
delete reset_pageswap
ENTSCHULDIGUNG also dafür das ich meinte die Funktion wäre nicht gegeben.
Toll wäre jetzt wenn das Popup die Möglichkeit hätte geänderte Werte auszuwählen (Checkbox) und die gewählten dann zu speichern.
Schönen Sonntag..!
Hallo zusammen,
find ich toll dieses Feature. Hut ab.
Bei mir sieht man nun, dass temporäre at's allerdings noch als strukturelle Änderung erkannt werden. Hier ist nun die Frage, ob man das so sehen kann oder nicht.
Bei einem global:INITIALIZED starte ich ein temporäres at mit 5 Sekunden Verzögerung um meine Jalousie-Automatik wieder in einen definierten Zustand zu bekommen.
define Jalousie_initial_set notify global:INITIALIZED define tmp_Reset_Jalousieautomatik at +00:00:05 {Jalousie_Automatik($we, 1)}
Richtigerweiße wurde in der vorherigen fhem.pl in der CommandDefine()-Funktion der $lastDefChange Zähler nur dann erhöht, wenn $hash->{TEMPORARY} nicht gesetzt war. Kann man das bei einem at, was nur einmal ausgeführt wird und sich anschließend selbst mit delete löscht nicht ebenfalls so implementieren, dass es $hash->{TEMPORARY} verpasst bekommt und dann entsprechend nicht gezählt wird beim definieren und löschen?
Viele Grüße
Markus
Zitat von: Markus Bloch am 25 Januar 2015, 12:01:27
find ich toll dieses Feature. Hut ab.
Gefällt mir auch sehr gut. Danke!
Bevor jetzt aber wieder ein S***storm losbricht bzw. Wehklagen einsetzt, daß das Feature nicht funktioniert: Beim Firefox mußte ich nach dem update und shutdown restart die FHEM Seite mit "Shift-Reload" neu laden. Vorher hat er zwar das rote Fragezeichen angezeigt, aber es war nicht "klickbar"...
@Markus: habe diese Sorte von at ausgeklammert.
Vielen Dank
Zitat von: rudolfkoenig am 25 Januar 2015, 13:43:48
@Markus: habe diese Sorte von at ausgeklammert.
Betrifft das auch die (zumindest bei FS20 Devices) bei Verwendung der follow-on-for-timer / follow-on-timer generierten define ..._timer und delete ..._timer? Die führen bei mir nämlich auch zu einem "roten Fragezeichen".
Wenn nicht, wäre das noch eine zusätzliche "Baustelle".
Ja, diese temporären FS20 timer werden nicht mehr berücksichtigt. Ich hatte mir heute Mittag die Änderung aus dem SVN eingetragen.
Na also, es geht ja doch auch "brauchbar" :)
Danke für die Korrekturen und Änderungen. Damit lässt sich doch gut leben.
Ich habe heute erstmals in deinem DOIF eine Global:Initialized-Zeile aufgenommen und einen Test-Neustart durchgeführt. Zeitlich danach habe ich plötzlich auch das rote Fragezeichen dort stehen.
Last 10 structural changes:
modify di_auto_jal_1 ([{getJalTime("workdayOpen...
modify di_auto_jal_1 ([{getJalTime("workdayOpen...
modify di_auto_jal_1 ([{getJalTime("workdayOpen...
modify di_auto_jal_1 ([{getJalTime("workdayOpen...
modify di_auto_jal_1 ([{getJalTime("workdayOpen...
modify di_auto_jal_1 ([{getJalTime("workdayOpen...
Wie bekomme ich das wieder weg?
Heißt das, dass ich etwas falsch gemacht habe?
Ein "Save" bringt bei mir keine Besserung.
Was ist mit "deinem DOIF" gemeint?
Waere das nicht eine Frage fuer DOIF?
Ich wollte eigentlich sagen: in einem DOIF
Update: ich hab das neue Feature jetzt verstanden und nun ist auch für mich nachvollziehbar, dass ich im Doif schauen muss.
Wenn man mit devspec arbeitet und beispielsweise ein
deleteattr TYPE=SVG plotsize
ausführt, steht in der Liste der nicht gespeicherten Änderungen ggf. 10 Mal "deleteattr TYPE=SVG plotsize" - schöner fände ich da jeweils den tatsächlichen deviceName
Zwar etwas uebertrieben, ich habs aber eingebaut.
naja, die Alternative wäre gewesen, die Info nur einmal auszugeben ;)
Das Fenster muss oft 2 mal mit ok bestätigt werden, bist es sich schließt. Hin und wieder geht es auch durch einen Klick. Ein Muster habe ich noch nicht erkannt.
@karl: Wenn du zwei, dreimal schnell hintereinander auf das Fragezeichen klickst, wird das Fenster an derselben Stelle 2, 3, xmal überlappend geöffnet.
Dann mussts natürlich auch mehrmals schliessen :D
Nein. Das ist nicht das Problem. Ich weiß, was ich tue.
einige meiner schaltvorgänge gehen gezielt auf disable attribute - in der lister der 10 änderungen wird jede dieser änderungen ebenfalls mitgeschrieben, natürlich ist das aus sicht der funktion richtig - aber vielleicht lassen sich änderungen die wieder rückgängig gemacht wurden irgendwie wieder aus der liste entfernen...