Aus der newsgroup: public.xbase++.workbench

Hallo Herr Martl,

Es besteht in der Workbench gegewärtig leider keine Möglichkeit andere
Fontgrößen zu manipulieren ausser dem Code Editor. Diesen Feature
Request haben wir bereits im Fokus, andere Modifikationen und
Verbesserungen haben aber derzeit eine höhere Priorität.

Ähnliches gilt auch für Ihre Anforderung Datum und Uhrzeit mit einer
Tastenkombination in den Quellcode einzutragen.

Was genau meinen Sie mit "Wiederherstellen der eingestellten Breite des
Projekt-Managers-Fensters". Ich habe hier bei mir die Breite des linken
Bereichs geänder, in dem der Projekt Manager angedockt war. Nach
einem Neustart der Workbench hat sich jener Bereich genau so gestaltet
wie vor dem Verlassen der Workbench.

Zum Thema Quellcode Dokumentation: Traditionell wird im Quellcode
vermerkt wo von wem welche Änderungen vorgenommen wurden. Dieser
Ansatz stammt von einer Zeit als Quellcode Repositories noch nicht vor-
handen oder zumindest nicht sehr verbreitet waren.

Wir raten dringend eine Versionsverwaltung für Ihren Xbase++ Quellcode
zu benutzen. Auf der diesjährigen Xbase++ Entwickler Konferenz in
Neu-Weilnau hat Andreas Engler einen wunderbaren Vortrag gehalten,
der die Vorteile einer solchen Software vorführt. Ich bin mir sicher, dass
der Vermerk einer Uhrzeit und eines Datums im Quellcode sich dann
überhohlt hat.

Ich meine mich zu entsinnen, dass Sie an der Konferenz teilgenommen
haben, Sie deshalb Zugang zu Andreas' (Engler) Konferenz Unterlagen
haben. Währe das nicht ein interressantes Studium für über
Weihnachten 

  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
--------------------------------------------------------------------

"Werner Martl" wrote in message 
news:18928865$28fa0f3c$14e63e@news.alaska-software.com...
> Servus Alaska,
>
> kann man in der WB die Schriftgrößen des Projekt-Managers, 
> Variablen-Fensters etc. auch einstellen? Sind sehr klein, kaum lesbar. Da 
> nur mein 2. Monitor (= WB-Monitor ;-)) 4k hat, möchte ich nicht generell 
> die Windows-Einstellungen dazu ändern.
>
> 2 Dinge fehlen mir noch bei der WB: Wiederherstellung der eingestellten 
> Breite des Projekt-Managers-Fensters und das Einfügen mittels 
> Tastenkombination des aktuellen Datums und / oder Uhrzeit (zwecks 
> Quellcode-Dokumentation).
>
> Danke!
>
> Werner

Am 16.12.2014 16:32, schrieb Andreas Herdt:
> Aus der newsgroup: public.xbase++.workbench
>
> Hallo Herr Martl,
>
> Es besteht in der Workbench gegewärtig leider keine Möglichkeit andere
> Fontgrößen zu manipulieren ausser dem Code Editor. Diesen Feature
> Request haben wir bereits im Fokus, andere Modifikationen und
> Verbesserungen haben aber derzeit eine höhere Priorität.
>
> Ähnliches gilt auch für Ihre Anforderung Datum und Uhrzeit mit einer
> Tastenkombination in den Quellcode einzutragen.
>
> Was genau meinen Sie mit "Wiederherstellen der eingestellten Breite des
> Projekt-Managers-Fensters". Ich habe hier bei mir die Breite des linken
> Bereichs geänder, in dem der Projekt Manager angedockt war. Nach
> einem Neustart der Workbench hat sich jener Bereich genau so gestaltet
> wie vor dem Verlassen der Workbench.

Ganz links bei mir in der Workbench ist das Fenster Project Manager  
Code Explorer und darunter Function  File. Das hat beim Start immer 
eine sehr schmale Breite, ich ziehe es dann breiter - damit wird das 
Fenster Variables / Threads schmäler. Beende ich die WB und starte neu, 
ist es leider wieder schmal.

>
> Zum Thema Quellcode Dokumentation: Traditionell wird im Quellcode
> vermerkt wo von wem welche Änderungen vorgenommen wurden. Dieser
> Ansatz stammt von einer Zeit als Quellcode Repositories noch nicht vor-
> handen oder zumindest nicht sehr verbreitet waren.
>
> Wir raten dringend eine Versionsverwaltung für Ihren Xbase++ Quellcode
> zu benutzen. Auf der diesjährigen Xbase++ Entwickler Konferenz in
> Neu-Weilnau hat Andreas Engler einen wunderbaren Vortrag gehalten,
> der die Vorteile einer solchen Software vorführt. Ich bin mir sicher, dass
> der Vermerk einer Uhrzeit und eines Datums im Quellcode sich dann
> überhohlt hat.
>
> Ich meine mich zu entsinnen, dass Sie an der Konferenz teilgenommen
> haben, Sie deshalb Zugang zu Andreas' (Engler) Konferenz Unterlagen
> haben. Währe das nicht ein interressantes Studium für über
> Weihnachten 
>
Da war ich leider nicht, da die Ankündigung viel zu kurzfristig war. Ich 
war letztes Jahr in Stuttgart und da auch in dem Vortrag von Andreas. 
Für die Versionsverwaltung extra einen eigenen Linux-Server aufzusetzen 
schien mir damals viel zu aufwändig. Ich benutze bisher lieber die 
vielen tollen Möglichkeiten des Compilers mit den Direktiven, damit 
kommen wir ganz gut klar. Ausserdem ist ja seitens Alaska da vieles 
angekündigt, was sich künftig diesbezüglich noch tun soll. Ein kurzes
   geändert 17.12.2014 13.03 Uhr durch WM
im Quellcode ist für unsere Belange völlig ausreichend. Erst ab 3-4 
Entwickler rentiert sich m. M. n. eine Versionsverwaltung.
Bei uns gibts die #ifdef TESTEN / #ifdef BETA - Schalter. 

Weihnachten ist ausgebucht mit Studium Xbase++ 2.0 - die neuen 
Möglichkeiten - und Umstellung bei den Kunden auf die 2.0 - möglich 
durch das letzte Update und dem Schalter für die C-DLLS.

Vielen Dank hierfür nochmal!

Werner Martl wrote:

> Da war ich leider nicht, da die Ankündigung viel zu kurzfristig war. Ich 
> war letztes Jahr in Stuttgart und da auch in dem Vortrag von Andreas. 
> Für die Versionsverwaltung extra einen eigenen Linux-Server aufzusetzen 
> schien mir damals viel zu aufwändig.

Völlig unnötig. Subversion läuft z.B. auch auf Windows Servern.

Mit GIT braucht man als Einzelentwickler nichtmal einen Server - ist
optimal für die typischen "one man show" Entwicklung. 

Besonders die Möglichkeit grafisch zu sehen was genau (und wann) sich
geändert hat ist manchmal Gold wert. Je mehr Entwickler involviert sind
umso wichtiger wird das.

Oder man benutzt einen privaten Account bei GIThub.

Oder man verwendet ein fertiges VMWare image von Bitnami.... die
Möglichkeiten sind vielfältig.

Es lohnt sich, mal einen Tag Zeit zu investieren und sich die Konzepte der
unterschiedlichen Versionsverwaltungen anzuschauen.

Ich z.B. verwende für eigtene Entwicklungen ausschließlich Subversion, der
Server läuft auf Windows 2008 R2 mit Apache 2.4.


grüße
Thomas

Am 18.12.2014 15:14, schrieb Thomas Braun:
> Werner Martl wrote:
>
>> Da war ich leider nicht, da die Ankündigung viel zu kurzfristig war. Ich
>> war letztes Jahr in Stuttgart und da auch in dem Vortrag von Andreas.
>> Für die Versionsverwaltung extra einen eigenen Linux-Server aufzusetzen
>> schien mir damals viel zu aufwändig.
>
> Völlig unnötig. Subversion läuft z.B. auch auf Windows Servern.
>
> Mit GIT braucht man als Einzelentwickler nichtmal einen Server - ist
> optimal für die typischen "one man show" Entwicklung.
>
> Besonders die Möglichkeit grafisch zu sehen was genau (und wann) sich
> geändert hat ist manchmal Gold wert. Je mehr Entwickler involviert sind
> umso wichtiger wird das.
>
> Oder man benutzt einen privaten Account bei GIThub.
>
> Oder man verwendet ein fertiges VMWare image von Bitnami.... die
> Möglichkeiten sind vielfältig.
>
> Es lohnt sich, mal einen Tag Zeit zu investieren und sich die Konzepte der
> unterschiedlichen Versionsverwaltungen anzuschauen.
>
> Ich z.B. verwende für eigtene Entwicklungen ausschließlich Subversion, der
> Server läuft auf Windows 2008 R2 mit Apache 2.4.
>
>
> grüße
> Thomas
>

Es gibt bitbucket.org, völlig kostenlos. Auch für mehr als einen 
Entwickler. Dazu noch SourceTree und man hat eine schöne Oberfläche.

Gruß
Markus

Markus Ratzesberger wrote:

> 
> Es gibt bitbucket.org, völlig kostenlos. Auch für mehr als einen 
> Entwickler. Dazu noch SourceTree und man hat eine schöne Oberfläche.

Die wenigsten Firmen werden - aus verständlichen Gründen - ihren Sourcecode
einfach irgendwo auf fremden Servern stehen haben wollen.

Da Atlassian (bitbucket) ein amerikanisches Unternehmen ist werden die
Server irgendwo in USA stehen... seit Snowden muss man da nicht wirklich
mehr sagen 

Wem das wurstegal ist kann natürlich auf bitbucket zurückgreifen 

grüße
Thomas