[C] Command line GUI Tool

[Spruit_elf]

Ik heb net een idee voor een programma
dat zou als het ware een grafische schil vormen voor diverse programmas die alleen met een command line werken. (Zoals bijvoorbeeld HTMLTidy)

het zou ongeveer als volgt moeten werken.

1. Het programma leest uit wat voor een parameters het uittevoeren programma nodig heeft/kan ontvangen
2. Bouwt daar een grafische interface omheen(kan heel simpel, zelfs een html

zou volstaan)
3. User input in die interface wordt vertaalt naar parameters
4. het uit tevoeren programma wordt uitgevoerd met de betreffende parameters

Dit alles zou dan vergezeld kunnen gaan door bijvoorbeeldd een database met beschikbare programmas oid of een sneltoets functionaliteit

maar afijn aangezien ik zelf niet erg veel programeer skills bezit, lijkt me dit een leuk project om mezelf eens een taal aan te leren.

Dit topic is dan ook niet bedoelt als scriptrequest oid.

Wat ik wel graag zou willen zien zijn opmerkingen over hoe zon programma zou moeten werken, sugesties qua ta(a)l(en) en andere nuttige bijdragen die mij zouden kunnen helpen om zo iets te maken


het grootste probleem is denk ik nog het uitlezen van de parameters.
zelf zat ik te denken aan de optie die de meeste programmas hebben dat ze laten zien wat de invoer moet zijn als je het programma uitvoert zonder parameters of met een parameter als /?.

een voorbeeld is
de output van "dir /?"

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\>dir /?
Displays a list of files and subdirectories in a directory.

DIR [drive:][path][filename] [/A[[:]attributes]] [/B] [/C] [/D] [/L] [/N]
  [/O[[:]sortorder]] [/P] [/Q] [/S] [/T[[:]timefield]] [/W] [/X] [/4]

  [drive:][path][filename]
              Specifies drive, directory, and/or files to list.

  /A          Displays files with specified attributes.
  attributes   D  Directories                R  Read-only files
               H  Hidden files               A  Files ready for archiving
               S  System files               -  Prefix meaning not
  /B          Uses bare format (no heading information or summary).
  /C          Display the thousand separator in file sizes.  This is the
              default.  Use /-C to disable display of separator.
  /D          Same as wide but files are list sorted by column.
  /L          Uses lowercase.
  /N          New long list format where filenames are on the far right.
  /O          List by files in sorted order.
  sortorder    N  By name (alphabetic)       S  By size (smallest first)
               E  By extension (alphabetic)  D  By date/time (oldest first)
               G  Group directories first    -  Prefix to reverse order
  /P          Pauses after each screenful of information.

het lijkt me dat de regel

DIR [drive:][path][filename] [/A[[:]attributes]] [/B] [/C] [/D] [/L] [/N]
  [/O[[:]sortorder]] [/P] [/Q] [/S] [/T[[:]timefield]] [/W] [/X] [/4]

opzich wel aftevangen moet zijn dat dar wel iets mee te doen moet zijn. het probleem blijft alleen dat niet alle programmas een dergelijke output geven.

punt 2 zou dan zijn dat er van die regel een formulier oid wordt gemaakt
waarbij alle verplichte (in dit geval is alles optioneel) velden ingevuld moeten worden.

en als mogelijk ook nog en soort van datatype herkening, zodat je bijvoorbeeld Bij het stukje [drive:][path][filename] een invul veld met een bladeren knop erbij.
en dat de [/B] [/C] [/D] [/L] [/N] atributen bij voorbeeld checkboxen zijn.

Punt 3 &4 lijken mij nu niet echt een probleem.

Tot zo ver mijn gedachten erover, ik hoop dat ik het een beetje duidlijk heb uitgelegd

Wat betreft de taal, het liefst zou ik een C variant willen gebruiken, omdat die richting voor mij nog een grijs/zwart gebied is. Graag ook wat tips/opmerkingen daar over.

Owja hou het aub ontopic, reacties die niets nuttigs toevoegen heb ik liever niet.

modbreak: dan moet je geen topic op een publiek forum plaatsen, en mocht het op een foute manier offtopic gaat lopen wij hier nog rond.

[ Voor 3% gewijzigd door curry684 op 10-08-2004 09:09 ]

[djc]

Denk niet dat het gaat werken om die opties zoals bij bijv /? gegeven te parsen en aan de hand daarvan opties te bieden aan de user. Eerder moet je denk ik gewoon voor elk programma dat je wil ondersteunen handmatig uitzoeken welke opties je nuttig vindt.

Dat gezegd hebbende moet ik zeggen dat ik je idee wel grappig vind, maar niet enorm nuttig.

[Verwijderd]

Het klinkt wel aardig, en voor mensen die niet zoveel computerkennis hebben zou het ook nog wel eens nuttig kunnen zijn. Maar zodra je een beetje meer feeling krijgt dan kun je toch wel met de console en console programma's uit de voeten?

Dat gezegd hebbende: om de mogelijkheden van een programma automatisch uit te laten zoeken aan de hand van een helpscherm lijkt me niet te doen; zo'n beetje elk programma heeft namelijk een ander helpscherm, en een andere manier om dat scherm te tonen (zonder parameters, /?, -?, -h, --help, etc.). Op Linux heb je denk ik nog een kans, omdat de GNU tooltjes over het algemeen een redelijk uniforme interface hebben (help vraag je op met --help, en die ziet er over het algemeen behoorlijk hetzelfde uit). Op Windows is het al vager. /? doet het meestal, maar er zit niet altijd een goed patroon in de invoer.

Wat overblijft is met de hand een invoerscherm voor elk programma bouwen (of toch een database van opties die voor een programma kunnen gelden). Dat kàn, maar dat is best een pokkewerk . Maar als je daar zin in hebt, ga vooral je gang .

En dan heb je nog het geval, vooral op *NIX-gebaseerde systemen, dat je om het meeste nut te hebben van je command-line tooltjes, je ze achter elkaar moet gaan schakelen met pipes |. Daar moet je dan eigenlijk ook voorzieningen voor inbouwen.

Maar uiteindelijk, als ik de keus heb tussen een minuut klikken en typen in een GUI, of het commando in 10 seconden in kan kloppen op een console (zonder mijn handen van het toestenbord af te hoeven halen), dan weet ik het wel...

(Jaja, je kan een GUI ook bedienen met alleen het toetsenbord, I know )

[Spruit_elf]

@oneofborg: afgezien dat het het voor mensen die een programma niet kennen makkelijker is om zon formulier in te vullen, geeft het ook een mogelijkkeid om bijvoorbeeld functied bij het programma te stoppen als het maken van .bat files, het maken van een databse van de op de computer beschikbare prgrammas ed.


Wat ik me wel af vraag, stel dat het toch te doen is om de output om te zetten, hoe zou ik doie dan het best afvangen is er een simpele manier waarop een programma een deregelijke output kan opvangen of moet ikdan gaan werken met vreemde constructies?

het zou denk ik nog best kunnen werken icm een database vor bekende programmas.

[dingstje]

Ik zie het nut niet in van een GUI dingetje dat gewoon de hele rits opties aframmelt. Je moet er de veelgebruikte uithalen en dan duidelijk vragen (in voor de user begrijpbare tekst) aan de user wat hij daarvoor wilt hebben.

[Rmg]

Als taal zou je delphi kunnen gebruiken en inderdaad gewoon de veel gebruikte opties nemen en daaruit laten kiezen ( je zal dus wel per programma moeten kijken welke opties je nodig hebt )

[Verwijderd]

mrcactus schreef op 10 augustus 2004 @ 11:34:
Wat ik me wel af vraag, stel dat het toch te doen is om de output om te zetten, hoe zou ik doie dan het best afvangen is er een simpele manier waarop een programma een deregelijke output kan opvangen of moet ikdan gaan werken met vreemde constructies?

Of het mogelijk is om de uitvoer van console-programma's in je eigen applicatie in te lezen? Jazeker. Dat werkt met "pipes" (een invoer/uitvoer kanaal). Als je een programma start, kun je zijn standaard-invoer en standaard-uitvoer verbinden aan een pipe die je zelf gemaakt hebt. Vervolgens kun je uit de standaard-uitvoer pipe lezen, of naar de standaard-invoer pipe schrijven, om het programma te "gebruiken" zoals iemand achter het toestenbord dat zou doen.

Ik geloof dat de call popen in C dit mogelijk maakt... en anders de Win32 API wel.

[Creepy]

Raz- schreef op 10 augustus 2004 @ 11:41:
Als taal zou je delphi kunnen gebruiken

Net als C, C++, VB, C#, VB.NET, ASM etc. etc. etc. Zo ontzettend veel mogelijkheden.....

[curry684]

Verwijderd schreef op 10 augustus 2004 @ 12:23:
[...]


Of het mogelijk is om de uitvoer van console-programma's in je eigen applicatie in te lezen? Jazeker. Dat werkt met "pipes" (een invoer/uitvoer kanaal). Als je een programma start, kun je zijn standaard-invoer en standaard-uitvoer verbinden aan een pipe die je zelf gemaakt hebt. Vervolgens kun je uit de standaard-uitvoer pipe lezen, of naar de standaard-invoer pipe schrijven, om het programma te "gebruiken" zoals iemand achter het toestenbord dat zou doen.

Ik geloof dat de call popen in C dit mogelijk maakt... en anders de Win32 API wel.

De wonderlijke functie 'CreatePipe' is daar inderdaad voor Die maakt een zogenaamde anonymous pipe tussen 2 related processes, en staat daar gesynchronizeerde communicatie over toe.

In MSDN staat een uitgebreide uitleg met complete voorbeeldcode onder de titel "Creating a Child Process with Redirected Input and Output".

[Spruit_elf]

Creepy schreef op 10 augustus 2004 @ 12:29:
[...]

Net als C, C++, VB, C#, VB.NET, ASM etc. etc. etc. Zo ontzettend veel mogelijkheden.....

jah maar ik denk zelf toch meer aan een wat 'lagere' taal zoals C(++) over VB.Net ed
en aangezien C(++) qua taal wel veel weg heeft van php, vind ik het makkelijskt om het daarin te maken, het probleem is alleen dat ik door de compilers en libs het bos neit echt zie.

Verder wou ik het als een oefenproject gaan gebruiken en een van de dingen waar ik me ook in verdiep momenteel is OOP, dus dat beperkt de mogelijkheden ook enigzins

curry684 schreef op 10 augustus 2004 @ 12:33:
[...]

De wonderlijke functie 'CreatePipe' is daar inderdaad voor Die maakt een zogenaamde anonymous pipe tussen 2 related processes, en staat daar gesynchronizeerde communicatie over toe.

In MSDN staat een uitgebreide uitleg met complete voorbeeldcode onder de titel "Creating a Child Process with Redirected Input and Output".

ik neem aan dat je dit artikel bedoelt, erg intresant, maar als ik het zo zie dan moet je vanuit het child process ook met die pipe werken en aangezien mijn 'child processen' niet van mij zijn is dat vrij onmogelijk

[ Voor 40% gewijzigd door Spruit_elf op 10-08-2004 12:42 ]

[Creepy]

mrcactus schreef op 10 augustus 2004 @ 12:38:
[...]

ik neem aan dat je dit artikel bedoelt, erg intresant, maar als ik het zo zie dan moet je vanuit het child process ook met die pipe werken en aangezien mijn 'child processen' niet van mij zijn is dat vrij onmogelijk

Je leidt de stdin en stdout (en eventueel stderr) van het proces om naar je pipes. Dat betekent dat de child processen niet hoeven worden aangepast. Die hebben niet door dat ze input krijgen van jou app i.p.v. de gebruiker en dat ze output sturen naar jou app i.p.v. het scherm

[-DarkShadow-]

mrcactus schreef op 10 augustus 2004 @ 12:38:
[...]


jah maar ik denk zelf toch meer aan een wat 'lagere' taal zoals C(++) over VB.Net ed
en aangezien C(++) qua taal wel veel weg heeft van php, vind ik het makkelijskt om het daarin te maken, het probleem is alleen dat ik door de compilers en libs het bos neit echt zie.

Verder wou ik het als een oefenproject gaan gebruiken en een van de dingen waar ik me ook in verdiep momenteel is OOP, dus dat beperkt de mogelijkheden ook enigzins

Ik ben op het moment aan het overstappen van VB naar C++. VB.NET geeft teveel overhead en VB6 heeft teveel beperkingen. En ik programmeer steeds minder voor win32. Ik ben C++ aan het leren aan de hand van thinking in C++ van Bruce Eckel. Ik gebruik als compiler dev-cpp en als ik iets moet weten over een libje, dan ga ik naar http://www.cppreference.com/. Als je je programma vooral met standaard libs opbouwt en voor de GUI zoiets a;s wxWindows gebruikt, dan is je programma ook nog eens goed te gebruiken op andere besturingssystemen. Ik denk dat je met deze info wel een tijdje aan de slag kunt.

[curry684]

mrcactus schreef op 10 augustus 2004 @ 12:38:
[...]

ik neem aan dat je dit artikel bedoelt, erg intresant, maar als ik het zo zie dan moet je vanuit het child process ook met die pipe werken en aangezien mijn 'child processen' niet van mij zijn is dat vrij onmogelijk

De code voor het gebruikte child process staat onderaan en komt het woord 'pipe' niet in voor.

[Spruit_elf]

-DarkShadow- schreef op 10 augustus 2004 @ 12:45:
[...]

Ik ben op het moment aan het overstappen van VB naar C++. VB.NET geeft teveel overhead en VB6 heeft teveel beperkingen. En ik programmeer steeds minder voor win32. Ik ben C++ aan het leren aan de hand van thinking in C++ van Bruce Eckel. Ik gebruik als compiler dev-cpp en als ik iets moet weten over een libje, dan ga ik naar http://www.cppreference.com/. Als je je programma vooral met standaard libs opbouwt en voor de GUI zoiets a;s wxWindows gebruikt, dan is je programma ook nog eens goed te gebruiken op andere besturingssystemen. Ik denk dat je met deze info wel een tijdje aan de slag kunt.

tnx daar kan ik idd iets mee
* Spruit_elf bookmarked site

curry684 schreef op 10 augustus 2004 @ 12:46:
[...]

De code voor het gebruikte child process staat onderaan en komt het woord 'pipe' niet in voor.

hmm zeker niet goed genoeg gekeken.
dus ga ik dat nog eens goed doen later.
maar ik kom createpipe niet tegen op http://www.cppreference.com/
uit welke taal/lib oid komt dat? als het alleen in de windows API voorkomt is dat niet echt een probleem, de input methode moet ik waarschijnlijk voor elk os anders maken en in eerste instantie maak het win only, maar met in me achterhoofd linux ed mogelijkheid. dat moet niet al te moeilijk zijn dmv classen en subclassen ed.


EDIT ik heb nog eens naar wat output van porgrammas gekeken en het probleem van -? /? -help - h dat moet wel lukken, gewoon alle opties proberen en kijken waneer er geldige output uit komt.

verder hebben de meeste programmas minstens 1 regel met alle opties en eigelijk altijd begint die met de naam van het programma gevolgd door de opties tussen [] dus het lijkt me dat dat ook wel te doen valt.

[ Voor 13% gewijzigd door Spruit_elf op 10-08-2004 13:07 ]

[curry684]

mrcactus schreef op 10 augustus 2004 @ 13:04:
[...]

hmm zeker niet goed genoeg gekeken.
dus ga ik dat nog eens goed doen later.
maar ik kom createpipe niet tegen op http://www.cppreference.com/
uit welke taal/lib oid komt dat? als het alleen in de windows API voorkomt is dat niet echt een probleem, de input methode moet ik waarschijnlijk voor elk os anders maken en in eerste instantie maak het win only, maar met in me achterhoofd linux ed mogelijkheid. dat moet niet al te moeilijk zijn dmv classen en subclassen ed

Uhhhh.... [google=CreatePipe], hit 1?

[Spruit_elf]

curry684 schreef op 10 augustus 2004 @ 13:06:
[...]

Uhhhh.... [google=CreatePipe], hit 1?

die had ik al gevonden, maar mijn kennis van C++ (en andere taalen die compilers nodig hebben) is iets te beperkt om te kunnen zien hoe ik die moet gebruiken.

klopt het als ik volgens dit stukje
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.

windows.h include dat het dan zou moeten werken? kunnen alle compilers dan daarmee overweg?
iets als
#include <windows.h>
?

[ Voor 4% gewijzigd door Spruit_elf op 10-08-2004 13:12 ]

[-DarkShadow-]

Gratis Compilers:
http://www.bloodshed.net/devcpp.html = simpel, dus aanrader
http://lab.msdn.microsoft.../get/default.aspx#express = Bèta express editie, dus niet lang houdbaar.
http://msdn.microsoft.com/visualc/vctoolkit2003/ Commandlinetool van MS VC6, veel functies voor output, maar geen GDE voor verkrijgbaar.

http://mindview.net/Books/TICPP/ThinkingInCPP2e.html = Handig EBook.

http://www.cpp-home.com/ = goed forum over cpp
www.cplusplus.com = zelfde als eerdere link, alleen dan slechter.

#include <windows.h> werkt in alle bovenstaande compilers.

[ Voor 11% gewijzigd door -DarkShadow- op 10-08-2004 13:31 ]

[curry684]

mrcactus schreef op 10 augustus 2004 @ 13:10:
[...]

Uhm ja je aanname klopt maar als je zo'n vraag stelt vraag ik me af of je niet veel te hoog springt met dit hele topic. Ik zou eens eerst een boek kopen als ik jou was, leren developen, en daarna pas een 'project' oppakken.

Tipje.

[Verwijderd]

#include <windows.h>

en dan niet vergeten windows.lib toe te voegen aan je project anders ben je nog nergens

[Soultaker]

Als reactie op de topicstart: ik betwijfel of het echt zinnig is om te proberen om allerlei tools te ondersteunen. De mogelijke parameters en de manier waarop die weergegeven worden verschillen teveel. Bovendien is het bijna onmogelijk om automatisch een logische weergave te maken van de opties.

Een handmatig ontworpen GUI heeft veel meer voordelen dan simpelweg kunnen klikken. Je kunt door zinnige widgets (controls) te gebruiken veel meer semantiek meegeven; denk aan radio-buttons voor elkaar uitsluitende opties, checkboxes voor opties die alleen aan- of uit kunnen zijn; edit-boxes (die tekst of alleen getallen accepteren). En dan heb ik het nog niet eens over het functioneel indelen van opties in tabbladen. Jouw automatische GUI zal het met afstand afleggen tegen een goede handmatig ontworpen GUI.

Verwijderd schreef op 10 augustus 2004 @ 09:29:
Het klinkt wel aardig, en voor mensen die niet zoveel computerkennis hebben zou het ook nog wel eens nuttig kunnen zijn. Maar zodra je een beetje meer feeling krijgt dan kun je toch wel met de console en console programma's uit de voeten?

Er zijn een heleboel programma's die ik zo sporadisch gebruik en die zo veel opties hebben dat ik het nooit leer. Als ik de LAME encoder gebruik bijvoorbeeld, moet ik altijd weer de opties nakijken. In zo'n geval zou een front-end best handig zijn (en daarvan bestaan er in dit voorbeeld ook een heleboel), zeker als die front-end extra hulpmiddelen biedt zoals onthouden wat de laatst ingestelde opties zijn.

[Rmg]

Creepy schreef op 10 augustus 2004 @ 12:29:
[...]

Net als C, C++, VB, C#, VB.NET, ASM etc. etc. etc. Zo ontzettend veel mogelijkheden.....

Als je als beginner GUI's wil maken lijkt me delphi toch ff makkelijker dan C C++ C# of asm

[Creepy]

Raz- schreef op 10 augustus 2004 @ 14:49:
[...]


Als je als beginner GUI's wil maken lijkt me delphi toch ff makkelijker dan C C++ C# of asm

offtopic:
Onderbouw dat dan de volgende keer als je roept "Je moet taal X of ontwikkelomgeving y gebruiken". Overigens is een GUI maken in C++ Builder net zo makkelijk als in Delphi. Een GUI in VB is ook niet zo moeilijk . Hell, met de nieuwe VS.NET is een GUI in C#.NET ook niet zo moeilijk!

[curry684]

Raz- schreef op 10 augustus 2004 @ 14:49:
[...]

Als je als beginner GUI's wil maken lijkt me delphi toch ff makkelijker dan C C++ C# of asm

C# en VB.NET zijn net zo simpel indien niet simpeler dan Delphi.

[Rmg]

Creepy schreef op 10 augustus 2004 @ 14:59:
[...]

offtopic:
Onderbouw dat dan de volgende keer als je roept "Je moet taal X of ontwikkelomgeving y gebruiken". Overigens is een GUI maken in C++ Builder net zo makkelijk als in Delphi. Een GUI in VB is ook niet zo moeilijk . Hell, met de nieuwe VS.NET is een GUI in C#.NET ook niet zo moeilijk!

Heb nooit gezegd je MOET, ik heb gezegd je zou delphi kunnen gebruiken. Ok ik een slecht onderbouwde mening, maar ik ben niet de enige die hier slecht onderbouwd he

Maargoed ik zou dus delphi pakken omdat het makkelijk onder de knie te krijgen is en dit soort voorbeelden bijna letterlijk in de help file zitten.
ook is de leercurve van delphi niet zo steil. Er is al ik me niet vergis ook al een personal edition te krijgen bij borland dus ook wat makkelijker te krijgen dan visual studio.

[Creepy]

Raz- schreef op 10 augustus 2004 @ 15:48:
[...]


Heb nooit gezegd je MOET, ik heb gezegd je zou delphi kunnen gebruiken. Ok ik een slecht onderbouwde mening, maar ik ben niet de enige die hier slecht onderbouwd he

True

Maargoed ik zou dus delphi pakken omdat het makkelijk onder de knie te krijgen is en dit soort voorbeelden bijna letterlijk in de help file zitten.
ook is de leercurve van delphi niet zo steil. Er is al ik me niet vergis ook al een personal edition te krijgen bij borland dus ook wat makkelijker te krijgen dan visual studio.

Al je argumenten gelden ook voor C++ Builder en VB.NEt en C#.NET volgens mij. Met SharpDevelop en de gratis .NET sdk heb je zelfs voor .NET een gratis ontwikkelomgeving.

Overigens staat in de Delphi help echt geen input/output redirection uitgelegd. Mocht dit wel zo zijn dan kan je me vast wel vertellen waar . Ook in Delphi ontkom je er niet aan om met CreateProcess te gaan werken.
In de Jedi VCL zit wel een CreateProcess component en deze stelt je ook in staat de output van het proces af te vangen, niet de input.

[Reptile209]

Je zou het programma met een (database van) ini-files kunnen laten werken. Dan zet je eenmalig de opties + invulvelden + "leesbare uitleg" in een ini-bestand. Het enige dat je programma dan moet kunnen doen is die ini inlezen (standaard werk) en dan vervolgens de gebruiker een lijst met al dan niet verplichte opties tonen.
Voorbeeldje voor ping:

code:

[Ping]
CommandLine="%windir%\ping.exe"
Comment="Stuurt testpakketjes van een bepaalde grootte naar 
      een lokaal- of internet-adres om verbindingen te testen."

[RequiredOptions]
Opt=""
Param=string
Comment="Het doel (bijv. www.utwente.nl of 130.89.1.16) 
      waarnaar gepingd moet worden"

[OptionalOptions]
Opt1="-a"
Param1="None"
Comment1="Een IP-adres als 130.89.1.16 proberen om te zetten 
      naar een servernaam."
Opt2="-n"
Param2="integer"
Comment2="Aantal ping-pakketten"
...

[Spruit_elf]

Reptile209 schreef op 10 augustus 2004 @ 16:23:
Je zou het programma met een (database van) ini-files kunnen laten werken. Dan zet je eenmalig de opties + invulvelden + "leesbare uitleg" in een ini-bestand. Het enige dat je programma dan moet kunnen doen is die ini inlezen (standaard werk) en dan vervolgens de gebruiker een lijst met al dan niet verplichte opties tonen.
Voorbeeldje voor ping:

code:

[Ping]
CommandLine="%windir%\ping.exe"
Comment="Stuurt testpakketjes van een bepaalde grootte naar 
      een lokaal- of internet-adres om verbindingen te testen."

[RequiredOptions]
Opt=""
Param=string
Comment="Het doel (bijv. www.utwente.nl of 130.89.1.16) 
      waarnaar gepingd moet worden"

[OptionalOptions]
Opt1="-a"
Param1="None"
Comment1="Een IP-adres als 130.89.1.16 proberen om te zetten 
      naar een servernaam."
Opt2="-n"
Param2="integer"
Comment2="Aantal ping-pakketten"
...

ik denk dta het makkelijker is om al die instellingen in 1 file te verwerken, wel was ik idd van plan het in een toegangeklijke file op te slaan zodat mensen zelf hun programma kunnen toevoegen bijvoorbeeld.

een ini file zou kunnen, dan moet ik eens gaan kijken naar de indeling van zulke files en wat het beste/simpelste is.

het zou zelfs, met oog op toekomst en compatibiliteit in een xml file kunnen

HTML:

<base>
 <programma>
  <titel>Ping</titel>
  <commandline>%windir%\ping.exe</commandline>
  <comment>Stuurt testpakketjes van een bepaalde grootte naar 
      een lokaal- of internet-adres om verbindingen te testen.</comment>
  <options>
   <option type="string">
    <title>URI<title>
    <comment>blaat</comment>
   </option>
  </options>
 </programma>
</base>

EDIT :zo iets dergelijks icm een eventuele XML parser lib , ik vermoed dat zoiets wel meot bestaan

qua GUI en de layout daarvan, XUL, is dat ene optie? wat zijn de pro's en con's van deze ideeën?

EDIT: Xul lijkt me alleen maar lastig, ga me eerst in wx windows verdiepen

[ Voor 33% gewijzigd door Spruit_elf op 10-08-2004 17:56 ]

[Reptile209]

Precies. Bijkomend voordeel is dat je het tot in het oneindige kan blijven uitbreiden, desnoods zelfs met verschillende versies (build, taal) van een programma. Mooi modulair, en je programma doet gewoon hetzelfde. Ook de pipes e.d. zou je op die manier kunnen definieren.

[Spruit_elf]

Reptile209 schreef op 10 augustus 2004 @ 17:38:
.....Ook de pipes e.d. zou je op die manier kunnen definieren....

Leg eens uit, dat hoort toch bij de basis van het programma, en zal alleen per OS verschillen, lijkt me.

dat lijkt me overbodig om dat in xml oid op te slaan

[Reptile209]

Ja, maar je kan wel aangeven hoe bepaalde data geformatteerd zal zijn in de pipe als het bijvoorbeeld uit ping afkomstig is. Dan kan je programma er bijvoorbeeld formatting, uitleg, enz. op loslaten.