Startup programma toekennen aan scherm

[Verwijderd]

Beste Tweakers,

Ik zit met een erg lastig probleem en ik hoop dat jullie me hier bij kunnen helpen. Ik ben momenteel bezig met het schrijven van een kassa. De software wordt geschreven in PHP en om de 'app' te tonen gebruiken we firefox. Deze start automatisch op bij het opstarten van de PC.

Nou heeft de kassa ook een tweede scherm voor de klanten om op mee te kunnen kijken. Hiervoor gebruiken we Chrome. Opzich gaat dit prima totdat we het tweede scherm verwijderen. Dan wordt Chrome geopend op het eerste scherm.

Chrome en Firefox worden geopend vanuit een batch bestand met daarin een timeout omdat het rechtstreeks aanroepen van de browsers vanuit de startup vaak een error gaf omdat de verbinding nog niet tot stand was gebracht.

Nu zoek ik dus een manier om dit probleem te onderscheppen. Ik hoor graag jullie suggesties!

Met vriendelijke groet,

Jurgen Bosch

[Yintha]

Wat is nou precies het probleem?

Opzich gaat dit prima totdat we het tweede scherm verwijderen. Dan wordt Chrome geopend op het eerste scherm.

Waarom verwijder je het tweede scherm?

[Janoz]

If all you have is a hammer, everything looks like a nail.

Zou het kunnen dat php gebruiken misschien niet helemaal de juiste keuze is geweest? Het komt op mij over als erg foutgevoelig, zeker wanneer je het hebt over een verzameling batch bestandjes welke 2 verschillende browser-smaken aan het opstarten is.

[Verwijderd]

Beste,

Zoals aangegeven betreft het een kassasysteem. Hierbij is continuïteit natuurlijk het aller belangrijkste. 'Mocht' de tweede monitor dus defect raken dan moet de kassa door draaien. Nu hebben we dus het tweede scherm op het eerste scherm staan zodra de kassa opstart. Dat is het probleem.

[Verwijderd]

Nou dan doe je toch alt+f4 als de tweede monitor stuk is gegaan,..

[Yintha]

Windowstoets + Shift + Pijltjestoetsen = vensters naar andere 'actieve' schermen verplaatsen

[Verwijderd]

Gelieve alleen serieuze reacties.

Ter verduidelijking: Ik schrijf de software voor onze klanten. Wij zijn dus niet fysiek aanwezig op deze locaties. Mijn klant uitleggen dat hij iedere keer Alt+F4 in moet drukken bij het opstarten is niet onze werkwijze.

Daarnaast het kassa systeem is volledig touchscreen, dus er zit geen toetsenbord bij aangezien deze niet nodig is.

[Verwijderd]

Kijk dat is wel fijne info om te noemen dat je geen tobo en muis hebt...

Kun je geen javascript gebruiken om een browser scherm te verplaatsen ?

[ Voor 34% gewijzigd door Verwijderd op 12-04-2012 10:08 ]

[Janoz]

Ik blijf er bij, (en wordt door je reacties hier alleen maar meer in versterkt): Een webbased systeem is hier niet de juiste keuze en ik vraag mij dan ook af hoe hier bij gekomen is. Je bent voor zover ik nu kan zien voornamelijk met symptoom bestrijding bezig. Wanneer je een native applicatie zou ontwikkelen heb je veel meer controle over welk window op welk scherm wat aan het tonen is, en wanneer ze opgestart worden.

[Zeebonk]

Ik sluit mij volledig bij Janoz aan. Door te kiezen voor een webbased systeem heb je het jezelf wel moeilijk gemaakt.

Als je dan toch hiermee verder moet zou ik de twee browser schermen (en mogelijk andere processen die worden gebruikt) laten starten en beheren met een AutoIt scriptje. Hier zou je om de zoveel tijd kunnen checken of er nog steeds twee schermen met de pc verbonden zijn (zo bijvoorbeeld) en de voor de klant zichbare browser kunnen hiden.

Is het een mooie oplossing? Ik vind van niet. Maar als je dan toch met batch scriptjes e.d. bezig ben, pak er dan een goede automation script omgeving bij.

[Verwijderd]

Ik ben het ook met Janoz eens. We hebben alleen niet de kennis van VB om een volledig native windows app te ontwikkelen. Vandaar dat we hebben gekozen voor een webbased applicatie. De applicatie draait momenteel geheel goed en vlekkeloos dus daar zijn we erg blij mee. We lopen nu alleen tegen dit soort obstakels aan, maar volgens mij kunnen we die ook wel overwinnen.

PS. Bedankt voor de tip van AutoIt. We hadden hier gister al even snel naar gekeken. Geweldige software en de link helpt echt! We gaan dit oppakken.

Dan nog een vraag: We runnen ook een aantal cronjobs voor bijv. de synchronisatie van nieuwe producten of prijswijzigingen. Zouden jullie dit gewoon via de Windows taakplanner laten doen of zouden jullie dit ook via AutoIt afvangen?

[Janoz]

Verwijderd schreef op donderdag 12 april 2012 @ 11:16:
Ik ben het ook met Janoz eens. We hebben alleen niet de kennis van VB om een volledig native windows app te ontwikkelen. Vandaar dat we hebben gekozen voor een webbased applicatie. De applicatie draait momenteel geheel goed en vlekkeloos dus daar zijn we erg blij mee. We lopen nu alleen tegen dit soort obstakels aan, maar volgens mij kunnen we die ook wel overwinnen.

Na dit obstakel volgen er gegarandeerd meer. Het is een doodlopende weg waarvan je het einde niet ziet omdat er allemaal hobbels voor staan. Nu is het het scherm, maar wat nu wanneer een klant straks vraagt een barcodescanner toe te voegen?

Ik zeg trouwens niet dat jullie je complete applicatie in de prullenbak moeten gooien. Absoluut niet. Het enige wat ik zeg is dat je het idee van een browser voor gui moeten laten varen. Je kunt ook een native client maken die alleen de grafische weergave en de input events afhandelt. Een native applicatie kan ook gewoon met een webserver (dus php) communiceren. Het grote voordeel is dat je dan niet te maken hebt met de sandbox van de browser en je enige beperking die van je eigen fantasie is.

Dan nog een vraag: We runnen ook een aantal cronjobs voor bijv. de synchronisatie van nieuwe producten of prijswijzigingen. Zouden jullie dit gewoon via de Windows taakplanner laten doen of zouden jullie dit ook via AutoIt afvangen?

hmm, dit vind ik wat vreemd. Betekend dit dat elke kassa eigenlijk ook zijn eigen webserver en database draait? Ik ging er tot nu toe van uit dat er 1 centrale server was waar alle kassa's mee verbonden. Dan zou je dit probleem helemaal niet moeten hebben.

[kwaakvaak_v2]

Ik hoop zo dat dit een schoolproject is... Anders zou ik alvast een investeringsronde willen voorstellen voor veel support tijd. Dat ga je wel nodig hebben namelijk.

Een kassa als webservice is opzichzelf geen dom idee, maar als je uitvoer volledig afhankelijk is van batch scriptjes, meerdere browser en taakplanner achtige toestanden... Dan wordt het een kwestie van wachten tot de telefoon weer gaat, omdat iemands browser gecrashed is etc. Er is een reden dat de meeste kassa systemen op embedded software draaien. Een kassa moet realtime zijn, en geen last hebben van achtergrond processen.

Sorry mevrouw de Klant, ik kan niet afrekenen met u, want mijn virusscanner is blijven hangen en mijn computer heeft momenteel een load van 95% En nee die kan ik ook niet afbreken, want ik heb geen toetsenbord. Wat zegt u? Opnieuw opstarten, oh ja dat is een goed idee.. Maar dat gaat ook even duren, want omdat ik de computer hard uit moet zetten gaat de mysql server eerst alle data controleren op eventueel corrupte data.

En wat nu als je meerdere terminals krijgt, worden dat dan allemaal standalone systemen en ga je die dan met een ingewikkeld script aan elkaar knopen?

Maar goed, als je perse iets met php wil doen, kijk een naar PHP-GTK, voor zover dat nog een beetje levend project is. Maar als je hier serieus je business van wilt maken, koop alsjeblieft een .net boek en ga uitzoeken hoe je in ieder geval een UI kunt maken die met je PHP kassa-webservice kan praten.

[YopY]

Verwijderd schreef op donderdag 12 april 2012 @ 11:16:
We hebben alleen niet de kennis van VB om een volledig native windows app te ontwikkelen.

Maar toch wel de vaardigheid - en de wil - om een nieuwe taal te leren? Als een klant wil dat jullie een kassasysteem bouwen dan moeten jullie eerst kijken welke taal en technologieën daar het beste voor werken; dat jullie toevallig een PHP club zijn betekent niet dat jullie zich daar strak aan moeten houden. Ik lees iets over Autoit scriptjes, cronjobs, batch scripts, twee verschillende browsers, lokaal draaiende webservers op kassasystemen etc; allemaal symptoombestrijding bij een verkeerde keuze qua omgeving (webbased), taal (php), etc.

[To_Tall]

Er zijn genoeg POS systemen op de markt, ook OS software..
Eerste zoek actie op Google http://www.google.nl/sear...ei=t_uJT5KBH6ex0AXWt9DgCQ

Deze systemen werken via een server based systeem.. Alle goederen die inkomen kan je hierin bijhouden. Vervolgens als een item wordt afgerekend wordt deze van de voorraad afgeboekt. Dus indien je dan een klant hebt die vraagt naar een item, kan je zo zien hoeveel je op voorraad hebt. Invetarisatie kan zo ook stuk korter duren

Ook kunnen deze POS systemen Journaal regels aanmaken voor je boekhouding..

Ook hierom denk ik dat je het wiel op nieuw aan het uitvinden bent.. Kijk eens naar andere POS systemen. Deze zijn niet op een webapplicatie geschreven. PHP is leuk voor websites net als ASP. Java applicatie, Volledig C++ geschreven apps. Of boekhoud pakketen met optie voor POS!!

[kwaakvaak_v2]

oh fuck... De TS is oprichter van prodes.nl, dit is dus geen school opdracht maar duidelijk een gevalletje verkeerde keuze en geen nee tegen een klant durven te verkopen en daarom ze maar opzadelen met een knutsel-werk-oplossing.


Oh en @To_Tall, Er is meer op aarde dan C++ om desktop applicaties te bouwen..

[Boss]

Jeemig zeg, wat een hoop negatieve reacties hier. Zonder dat ook maar iemand de oplossing heeft gezien of inhoud heeft genomen van de werking wordt het helemaal afgebrand. Ik ken TS niet, maar ben hier op Tweakers nog nooit zo'n aframmeling tegen gekomen, naar mijn mening onterecht. Is dat nu echt nodig?

Zie het eens andersom: Interessante benadering, een kassa als web-app. Leuke uitdaging. Vertel eens, TS, hoe heb je dat aangepakt?

[Janoz]

Alhoewel de laatste paar reacties ietwat aan de harde kant zijn vind ik het persoonlijk niet onterecht. Ik denk dat de volgende blogpost erg van toepassing is op deze discussie:

http://weblogs.asp.net/al...ve/2005/05/25/408925.aspx

[CodeCaster]

Ik snap de aversie jegens PHP als kassa-applicatie ook niet, afgezien van het feit dat het de afgelopen week in de devschuur weer PHP-bash-tijd lijkt te zijn, een regelmatig terugkerend fenomeen.

PHP kan in sommige gevallen een prima tool zijn om een dergelijk systeem te bouwen. Ik zou niet weten wat een executable hier voor voordeel zou kunnen leveren. De UI-technieken zijn webbased in mijn ervaring in ieder geval een stuk breder en gemakkelijker inzetbaar dan, zeg, WinForms of Swing, maar een en ander is behoorlijk afhankelijk van de eisen van de klant en je eigen kennen en kunnen. Zeggen dat PHP voor een dergelijke oplossing ongeschikt is, is mijn inziens dus ook wat voorbarig.

En een barcodescanner bedienen is geen enkel probleem, die dingen doen zich gewoon als HID voor en tikken de barcode in, gevolgd door een enter. Low-tech à la SendKeys? Nou en, het werkt toch, en dat blijft het ook doen. Hoe is een native implementatie 'beter'? Het zal het je klant een worst zijn of de barcode via een HID of een API binnenkomen, het zijn toch allemaal TLA's voor hem.

Dat gezegd hebbende: gezien de rest van de reacties van TS, vermoed ik dat dit door gebrek aan kennis een support-drama gaat worden. Maar dat zal een les voor de toekomst worden.

[ Voor 5% gewijzigd door CodeCaster op 16-04-2012 12:23 ]

[Janoz]

Een browser gebruiken voor het client deel is gewoon niet the right tool for the job. Ja, een handscanner is een HID, maar om gegarandeerd elke toetsaanslag op te kunnen vangen is een browser niet geschikt. Wat nu als de focus op het verkeerde van de 2 schermen terecht komt? Of toevallig net een page reload oid is? Dan heb je zo een paar toetsaanslagen gemist. En wat nu als je een rfid scanner toe wilt voegen? Of dat de kassa applicatie een geldla moet openen?

Het kan werken? Ja, maar met een beetje je best doen lukt het je ook wel om een spijker in de muur te slaan met een glazen fles.

Tot slot:

De UI-technieken zijn webbased in mijn ervaring in ieder geval een stuk breder en gemakkelijker inzetbaar dan, zeg, WinForms of Swing

Dit is natuurlijk complete onzin. Een clientside native app heeft per definitie meer mogelijkheden dan een webbassed app. Al was het alleen maar omdat je in je applicatie gewoon een webcomponent op kunt nemen.

[CodeCaster]

Natuurlijk zijn er legio redenen te bedenken waarom het niet werkt of welke tools de aanpak een heel andere invalshoek zouden geven, ik doelde alleen een aantal zaken aan te stippen die het voor hen wellicht tot een logische oplossing hebben gemaakt en hoe het in dit geval dus kan werken.

Uiteraard zou om nog meer redenen een native applicatie een betere oplossing zijn. Je kunt de aanwezigheid van de schermen detecteren, je kunt de hardware (scanners, lades, bonprinters, enzovoorts) direct aanspreken, et cetera, maar daar had ik het dus niet over, ik nam de situatie zoals beschreven voor lief.

[Wolfboy]

Als je Linux/Unix zou gebruiken met Opera dan kan je het commandline gewoon opgeven: http://www.opera.com/docs/switches/#unix

-windowname customers
-display :1
-kioskmode

[NMe]

Ik begrijp niet zo waarom hier zo wordt afgegeven op de negatieve opmerkingen in dit topic. Voor zover ik kan zien zijn ze gewoon beschaafd, en vanuit ethisch oogpunt ook correct. Te meer omdat de topicstarter dit zegt:

Verwijderd schreef op donderdag 12 april 2012 @ 11:16:
Ik ben het ook met Janoz eens. We hebben alleen niet de kennis van VB om een volledig native windows app te ontwikkelen.

Er is dus willens en wetens gekozen voor een systeem dat fundamenteel minder geschikt of zelfs tot op zekere hoogte ongeschikt is, en dan alleen omdat er geen kennis in-house is voor het ontwikkelen van native apps. In dat geval heeft degene die de opdracht binnengehaald heeft met alle voorkennis een opdracht binnengehaald waarvan hij of zij van tevoren wist dat het wel eens niet lekker zou kunnen gaan lopen. Ik vind dat je dan als bedrijf aan je oren moet krabben. Als wij op het kantoor waar ik werk geen vertrouwen hebben in oplevering die aan onze eigen standaarden voldoet, dan nemen we de opdracht niet aan.

Inhoudelijk: misschien is de Active Desktop een oplossing? Ik heb eigenlijk geen idee of die nog beschikbaar is in de laatste versies van Windows, maar als je een iframe kan opnemen op de desktop die verwijst naar je app dan verdwijnt die gewoon achter Firefox als het tweede scherm er niet is, en als het scherm er wel is breidt de desktop daar gewoon naar uit. Heb je meteen ook nog maar één browser nodig.

[.oisyn]

CodeCaster schreef op maandag 16 april 2012 @ 12:22:
Ik snap de aversie jegens PHP als kassa-applicatie ook niet, afgezien van het feit dat het de afgelopen week in de devschuur weer PHP-bash-tijd lijkt te zijn, een regelmatig terugkerend fenomeen.

Sure, schuif het maar weer af op "PHP bashen", da's makkelijk want dan hoef je je keuze niet meer goed te kunnen praten. Gaat natuurlijk nergens over. Temeer omdat niemand het hier ook maar in de mond heeft genomen dat het aan PHP ligt. Het was de browser-oplossing die niet voldeed, en of je nou PHP, ASP of NodeJS voor je webserver gebruikt doet compleet niet terzake. Of beweer je nu dat al dat ge-PHP-bash tegen browsers en webservices in het algemeen was gericht?

[ Voor 6% gewijzigd door .oisyn op 17-04-2012 14:04 ]

[HuHu]

Indien mogelijk, vervang je batch-scriptjes door een PowerShell-script dat het aantal aangesloten monitoren opvraagt. Afhankelijk van het resultaat start je dan één of twee browsers op.

[TheNephilim]

Als PHP ontwikkelaar/knutselaar moet ik zeggen dat het mij ook geen goede oplossing lijkt.

Is het niet een idee om dit met Adobe Air op te lossen? Dan laat je gewoon een HTML5/CSS/JS GUI tegen je PHP service aan praten (JSON). Dan heb je vrij simpel een 'native' app neergezet en kun je toch gebruik maken van de voor jou bekende technieken.

[CodeCaster]

NMe schreef op dinsdag 17 april 2012 @ 13:48:
Ik begrijp niet zo waarom hier zo wordt afgegeven op de negatieve opmerkingen in dit topic. Voor zover ik kan zien zijn ze gewoon beschaafd, en vanuit ethisch oogpunt ook correct.

Oh?

.oisyn schreef op dinsdag 17 april 2012 @ 13:54:
da's makkelijk want dan hoef je je keuze niet meer goed te kunnen praten

ik doelde alleen een aantal zaken aan te stippen die het voor hen wellicht tot een logische oplossing hebben gemaakt

Ik hoop niet dat mijn reacties tot het denkbeeld hebben geleid dat ik de door de TS verzonnen oplossing een goede oplossing vind, noch de genoemde alternatieven slecht. Ik hoef toch echter niet meteen aangevallen te worden als ik een andere invalshoek dan het elkaar napraten neem, toch?

Vervang, als je dat makkelijker vind lezen, het woord PHP in mijn post dan even door "een weboplossing", en denk de (toegegeven, wat makkelijk gemaakte) opmerking over het PHP bashen even weg.

[_trickster_]

Ik ben geen tegenstander van Weboplossingen voor dergelijke systemen, er is alleen wel 1 maar.

Het volledig vertrouwen op een brower, waarvan de technieken op dit moment zo snel veranderen lijkt mij niet helemaal de goede keuze, ook om de look-en-feel in eigen hand te houden.
met is van programeer kennis in een andere taal is het heel goed mogelijk om bijvoorbeeld in VB de Firefox browser te intergreren ( Gecko Framework dacht ik ).

hierbij maak je zelf een App, waarin de browser zit die de web-pagina laad,
het voordeel van deze setup is dat je met op een hoger niveau kan babbelen met windows, zoals Applicaties starten, schermen uitlezen, scherm bij uitval opmerken en daar op inspringen.
ook zal op deze manier niet snel de look-en-feel van de browser veranderen, en ook aanpassingen in de browser waarop je web-based syteem op reageerd veranderen zonder dat je daar erg in hebt ( auto-update ).
Zo kan je update's zelf makkelijk uitrollen, en in een test-omgeving eerst kijken of alles nog goed naar behoren werkt.

[BertS]

Leuk om je browser te integreren, maar hoe ben je dan precies minder afhankelijk van je browser? Als Firefox geüpdate wordt, geldt dat ook voor de onderliggende engine die door jouw Windows-app wordt geïntegreerd.

[Styxxy]

BertS schreef op woensdag 18 april 2012 @ 20:08:
Leuk om je browser te integreren, maar hoe ben je dan precies minder afhankelijk van je browser? Als Firefox geüpdate wordt, geldt dat ook voor de onderliggende engine die door jouw Windows-app wordt geïntegreerd.

Neen, je integreerd de engine in jouw applicatie, dus je hebt ook controle over het updaten van die engine etc. Met dit model ga je proberen de twee werelden te combineren (ik ga geen oordeel vellen of dat het goed/slecht is, daarvoor heb ik het niet genoeg onderzocht).

[BertS]

Ah op die manier. Ik las het meer als een 'browser-control'. My bad.

[.oisyn]

CodeCaster schreef op woensdag 18 april 2012 @ 18:37:
Vervang, als je dat makkelijker vind lezen, het woord PHP in mijn post dan even door "een weboplossing", en denk de (toegegeven, wat makkelijk gemaakte) opmerking over het PHP bashen even weg.

Nee, dat doe ik niet, want het PHP-bash gedeelte is precies de reden waarom ik erop reageerde, niet de rest van je post . Als je dat niet bedoelde, soit, maar dan had je dat ook niet moeten zeggen.

[ Voor 5% gewijzigd door .oisyn op 19-04-2012 09:56 ]