In der VX gab es folgende Funktionalitäten:
- F9 erzeugte ALLE dll und exe in einem Projekt neu, in denen mind. eine 
prg seit dem letzten kompilieren geändert worden war.
- Wurde während des debuggens Code geändert, wurde beim nächsten 
F9/F10/F6 erst Bescheid gegeben, das sich etwas geändert hat. Verbunden 
mit der Frage, ob neu kompiliert werden soll.

Beides funktioniert unter der Workbench so nicht mehr.

Ändere ich also Code in einer prg aus einer dll, muß ich erst ALT-F9 
drücken, und dann nochmal F9. Umständlich.

Ändere ich während debuggens Code, läuft der debugger nach F8/F9/F10 
ohne Rückfrage einfach weiter durch. Auch hier also erst ALT-F9 + F9. 
Was aber leider nicht immer funktioniert, in ca. 30-50% aller Fälle 
stürzt die Workbench dabei kommentarlos ab. Die geänderten Codeteile 
bleiben dabei meist (nicht immer) gespeichert.

Jan

Hallo Jan,

Die Workbench hat in bezug auf das automatische Neuerstellen
des Projekts dahingehend eine Änderung erfahren, als dass nun
das aktive Target in einem Projekt maßgeblich ist. Im Message
Fenster siehst du nicht mehr

pbuild project.xpj

sondern

pbuild /t:App.exe project.xpj

Es wird also das aktive Target gebaut.

Das betrifft auch die Behandlung von verändertem Quellcode. Ist
die exe das aktive Target und wird Quellcode aus einer DLL ver-
ändert, dann ist diese Veränderung für nicht signifikant für das exe
Target.

Dieses neue Verhalten wurde eingeführt, weil es bei komplexen
Projekten flexibler und effizienter ist. Zum Beispiel ist es möglich
in einem Projekt einen Client und einen Server zu verwalten, den
Server zu starten und am Client zu arbeiten. Das war vorher nicht
möglich.

Die Lösung für dich ist also jene DLL als aktives Target zu selektieren
an der du arbeitest. Trage eine Host Application für das DLL Target
ein und du hast ähnlich komfortables Verhalten wie früher.

Wir haben bereits vorgesehen das Verhalten konfigurierbar zu
machen. Man kann dann zwischen "Projekt zentrisch" und "Target
zentrischer" Sicht wählen.

Kann es sein, dass das Beenden der Workbench im Zusammenhang
mit der "Inspect Access/Assign" Debugger Einstellungen steht?

Mit freundlichen Grüssen,

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Jan Escholt" wrote in message 
news:5199304a$7f499c36$1d0734@news.alaska-software.com...
> In der VX gab es folgende Funktionalitäten:
> - F9 erzeugte ALLE dll und exe in einem Projekt neu, in denen mind. eine 
> prg seit dem letzten kompilieren geändert worden war.
> - Wurde während des debuggens Code geändert, wurde beim nächsten F9/F10/F6 
> erst Bescheid gegeben, das sich etwas geändert hat. Verbunden mit der 
> Frage, ob neu kompiliert werden soll.
>
> Beides funktioniert unter der Workbench so nicht mehr.
>
> Ändere ich also Code in einer prg aus einer dll, muß ich erst ALT-F9 
> drücken, und dann nochmal F9. Umständlich.
>
> Ändere ich während debuggens Code, läuft der debugger nach F8/F9/F10 ohne 
> Rückfrage einfach weiter durch. Auch hier also erst ALT-F9 + F9. Was aber 
> leider nicht immer funktioniert, in ca. 30-50% aller Fälle stürzt die 
> Workbench dabei kommentarlos ab. Die geänderten Codeteile bleiben dabei 
> meist (nicht immer) gespeichert.
>
> Jan

Hallo Andreas,

vielen Dank für die detaillierte Antwort.

Den einen Punkt hatten wir ja schon persönlich besprochen (bei 
Änderungen in der dll wird diese nicht neu kompiliert). Danke für die 
Bestätigung, das ich wahlweise das alte Verhalten wieder werde 
einstellen können. Kannst Du schon abschätzen, wann das Update 
freigegeben werden wird?

Das andere Problem wurde mir erst in den vergangenen Tagen bewußt. Ich 
fände es gut, wenn da das alte Verhalten wiederhergestellt werden 
könnte. Da kam bei Codeänderungen während des Debugger-Laufes ja die 
Abfrage, ob ich vor der Fortsetzung neu kompilieren möchte oder nicht. 
Das fand ich immer sehr richtig, denn manchmal bedeutet eine 
Codeänderung eben, das die Änderungen vor der Fortsetzung berücksichtigt 
werden müssen. Manchmal aber eben auch nicht.

Die Frage mit "Inspect Access/Assign" versteh ich nicht. Die Option ist 
angehakt, das war sie aber soweit ich weiß schon immer, auch in VX. Die 
Abstürze kommen auch nicht reproduzierbar. Das einzig Gleiche ist, das 
ich den Code ändere und dann Alt-F9 drücke, die Abfrage dann bestätige. 
Und das es keinerlei Fehlermeldung gibt. Workbench und Debuggee sind 
einfach weg.

Jan

Am 12.12.2014 um 11:16 schrieb "Andreas Herdt":
> Hallo Jan,
>
> Die Workbench hat in bezug auf das automatische Neuerstellen
> des Projekts dahingehend eine Änderung erfahren, als dass nun
> das aktive Target in einem Projekt maßgeblich ist. Im Message
> Fenster siehst du nicht mehr
>
> pbuild project.xpj
>
> sondern
>
> pbuild /t:App.exe project.xpj
>
> Es wird also das aktive Target gebaut.
>
> Das betrifft auch die Behandlung von verändertem Quellcode. Ist
> die exe das aktive Target und wird Quellcode aus einer DLL ver-
> ändert, dann ist diese Veränderung für nicht signifikant für das exe
> Target.
>
> Dieses neue Verhalten wurde eingeführt, weil es bei komplexen
> Projekten flexibler und effizienter ist. Zum Beispiel ist es möglich
> in einem Projekt einen Client und einen Server zu verwalten, den
> Server zu starten und am Client zu arbeiten. Das war vorher nicht
> möglich.
>
> Die Lösung für dich ist also jene DLL als aktives Target zu selektieren
> an der du arbeitest. Trage eine Host Application für das DLL Target
> ein und du hast ähnlich komfortables Verhalten wie früher.
>
> Wir haben bereits vorgesehen das Verhalten konfigurierbar zu
> machen. Man kann dann zwischen "Projekt zentrisch" und "Target
> zentrischer" Sicht wählen.
>
> Kann es sein, dass das Beenden der Workbench im Zusammenhang
> mit der "Inspect Access/Assign" Debugger Einstellungen steht?
>
> Mit freundlichen Grüssen,
>

Hallo Jan,

> könnte. Da kam bei Codeänderungen während des Debugger-Laufes ja die 
> Abfrage, ob ich vor der Fortsetzung neu kompilieren möchte oder nicht. Das 
> fand ich immer sehr richtig, denn manchmal bedeutet eine Codeänderung 
> eben, das die Änderungen vor der Fortsetzung berücksichtigt werden müssen. 
> Manchmal aber eben auch nicht.

Wie bereits gesagt: Wähle bitte jenes (dll) Target als aktives, an dem du
arbeitest. Das kommt in deinem Fall dem früheren Verhalten am nächsten.

> Die Frage mit "Inspect Access/Assign" versteh ich nicht. Die Option ist 
> angehakt, das war sie aber soweit ich weiß schon immer, auch in VX. Die

Wenn du die Option abwählst, verbessert sich dann die Stabilität?

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Jan Escholt" wrote in message 
news:f78b515$2a095156$225d4d@news.alaska-software.com...
> Hallo Andreas,
>
> vielen Dank für die detaillierte Antwort.
>
> Den einen Punkt hatten wir ja schon persönlich besprochen (bei Änderungen 
> in der dll wird diese nicht neu kompiliert). Danke für die Bestätigung, 
> das ich wahlweise das alte Verhalten wieder werde einstellen können. 
> Kannst Du schon abschätzen, wann das Update freigegeben werden wird?
>
> Das andere Problem wurde mir erst in den vergangenen Tagen bewußt. Ich 
> fände es gut, wenn da das alte Verhalten wiederhergestellt werden könnte. 
> Da kam bei Codeänderungen während des Debugger-Laufes ja die Abfrage, ob 
> ich vor der Fortsetzung neu kompilieren möchte oder nicht. Das fand ich 
> immer sehr richtig, denn manchmal bedeutet eine Codeänderung eben, das die 
> Änderungen vor der Fortsetzung berücksichtigt werden müssen. Manchmal aber 
> eben auch nicht.
>
> Die Frage mit "Inspect Access/Assign" versteh ich nicht. Die Option ist 
> angehakt, das war sie aber soweit ich weiß schon immer, auch in VX. Die 
> Abstürze kommen auch nicht reproduzierbar. Das einzig Gleiche ist, das ich 
> den Code ändere und dann Alt-F9 drücke, die Abfrage dann bestätige. Und 
> das es keinerlei Fehlermeldung gibt. Workbench und Debuggee sind einfach 
> weg.
>
> Jan
>
> Am 12.12.2014 um 11:16 schrieb "Andreas Herdt":
>> Hallo Jan,
>>
>> Die Workbench hat in bezug auf das automatische Neuerstellen
>> des Projekts dahingehend eine Änderung erfahren, als dass nun
>> das aktive Target in einem Projekt maßgeblich ist. Im Message
>> Fenster siehst du nicht mehr
>>
>> pbuild project.xpj
>>
>> sondern
>>
>> pbuild /t:App.exe project.xpj
>>
>> Es wird also das aktive Target gebaut.
>>
>> Das betrifft auch die Behandlung von verändertem Quellcode. Ist
>> die exe das aktive Target und wird Quellcode aus einer DLL ver-
>> ändert, dann ist diese Veränderung für nicht signifikant für das exe
>> Target.
>>
>> Dieses neue Verhalten wurde eingeführt, weil es bei komplexen
>> Projekten flexibler und effizienter ist. Zum Beispiel ist es möglich
>> in einem Projekt einen Client und einen Server zu verwalten, den
>> Server zu starten und am Client zu arbeiten. Das war vorher nicht
>> möglich.
>>
>> Die Lösung für dich ist also jene DLL als aktives Target zu selektieren
>> an der du arbeitest. Trage eine Host Application für das DLL Target
>> ein und du hast ähnlich komfortables Verhalten wie früher.
>>
>> Wir haben bereits vorgesehen das Verhalten konfigurierbar zu
>> machen. Man kann dann zwischen "Projekt zentrisch" und "Target
>> zentrischer" Sicht wählen.
>>
>> Kann es sein, dass das Beenden der Workbench im Zusammenhang
>> mit der "Inspect Access/Assign" Debugger Einstellungen steht?
>>
>> Mit freundlichen Grüssen,
>>

Hallo Andreas,

leider nützt Dein Hinweis mit dem Wechsel des Targets nichts. Denn wenn 
die dll das Target ist, dann klappt das überhaupt nicht mehr - eine dll 
kann ich nicht starten. F9 bringt mir da nur eine entsprechende Meldung, 
die mich in dem Moment eher nicht weiter voran bringt.

Das mit dem Abschalten der Option werde ich testen und später berichten.

Jan

Am 15.12.2014 um 11:17 schrieb "Andreas Herdt":
> Hallo Jan,
>
>> könnte. Da kam bei Codeänderungen während des Debugger-Laufes ja die
>> Abfrage, ob ich vor der Fortsetzung neu kompilieren möchte oder nicht.
>> Das fand ich immer sehr richtig, denn manchmal bedeutet eine
>> Codeänderung eben, das die Änderungen vor der Fortsetzung
>> berücksichtigt werden müssen. Manchmal aber eben auch nicht.
>
> Wie bereits gesagt: Wähle bitte jenes (dll) Target als aktives, an dem du
> arbeitest. Das kommt in deinem Fall dem früheren Verhalten am nächsten.
>
>> Die Frage mit "Inspect Access/Assign" versteh ich nicht. Die Option
>> ist angehakt, das war sie aber soweit ich weiß schon immer, auch in
>> VX. Die
>
> Wenn du die Option abwählst, verbessert sich dann die Stabilität?
>

Am 15.12.2014 21:27, schrieb Jan Escholt:
> Hallo Andreas,
>
> leider nützt Dein Hinweis mit dem Wechsel des Targets nichts. Denn wenn
> die dll das Target ist, dann klappt das überhaupt nicht mehr - eine dll
> kann ich nicht starten. F9 bringt mir da nur eine entsprechende Meldung,
> die mich in dem Moment eher nicht weiter voran bringt.
>
> Das mit dem Abschalten der Option werde ich testen und später berichten.
>
> Jan
>
> Am 15.12.2014 um 11:17 schrieb "Andreas Herdt":
>> Hallo Jan,
>>
>>> könnte. Da kam bei Codeänderungen während des Debugger-Laufes ja die
>>> Abfrage, ob ich vor der Fortsetzung neu kompilieren möchte oder nicht.
>>> Das fand ich immer sehr richtig, denn manchmal bedeutet eine
>>> Codeänderung eben, das die Änderungen vor der Fortsetzung
>>> berücksichtigt werden müssen. Manchmal aber eben auch nicht.
>>
>> Wie bereits gesagt: Wähle bitte jenes (dll) Target als aktives, an dem du
>> arbeitest. Das kommt in deinem Fall dem früheren Verhalten am nächsten.
>>
>>> Die Frage mit "Inspect Access/Assign" versteh ich nicht. Die Option
>>> ist angehakt, das war sie aber soweit ich weiß schon immer, auch in
>>> VX. Die
>>
>> Wenn du die Option abwählst, verbessert sich dann die Stabilität?
>>
Hallo Jan,
dann setze mal den Parameter "Host Application", dann kannst du auch 
über diese die entsprechende DLL ausführen.

Hallo Andreas,

leider kann ich nicht bestätigen, das es so stabiler läuft.

Das Problem mit dem doppelten Shortcut betätigen und das mit der 
fehlenden Nachfrage bei Codeänderungen während des Debuggens ist auch 
noch offen.

Jan


Am 15.12.2014 um 21:27 schrieb "Jan Escholt":
> Hallo Andreas,
>
> leider nützt Dein Hinweis mit dem Wechsel des Targets nichts. Denn wenn
> die dll das Target ist, dann klappt das überhaupt nicht mehr - eine dll
> kann ich nicht starten. F9 bringt mir da nur eine entsprechende Meldung,
> die mich in dem Moment eher nicht weiter voran bringt.
>
> Das mit dem Abschalten der Option werde ich testen und später berichten.
>
> Jan
>
> Am 15.12.2014 um 11:17 schrieb "Andreas Herdt":
>> Hallo Jan,
>>
>>> könnte. Da kam bei Codeänderungen während des Debugger-Laufes ja die
>>> Abfrage, ob ich vor der Fortsetzung neu kompilieren möchte oder nicht.
>>> Das fand ich immer sehr richtig, denn manchmal bedeutet eine
>>> Codeänderung eben, das die Änderungen vor der Fortsetzung
>>> berücksichtigt werden müssen. Manchmal aber eben auch nicht.
>>
>> Wie bereits gesagt: Wähle bitte jenes (dll) Target als aktives, an dem du
>> arbeitest. Das kommt in deinem Fall dem früheren Verhalten am nächsten.
>>
>>> Die Frage mit "Inspect Access/Assign" versteh ich nicht. Die Option
>>> ist angehakt, das war sie aber soweit ich weiß schon immer, auch in
>>> VX. Die
>>
>> Wenn du die Option abwählst, verbessert sich dann die Stabilität?
>>