onderscheid tussen design-time & run-time

[pkouwer]

Hi,
Ik wil onderscheid kunnen maken tussen mijn VB-appl. wat draait in de design-time & run-time.

Als het programma via een exe gestart wordt, var = 1, als hij gestart wordt vanuit VB-IDE dan var = 0. Is dit mogelijk ?

[johnwoo]

Probeer dit eens:

code:

Public Function InIDE() As Boolean 
    Debug.Assert Not TestIDE(InIDE) 
End Function 
Private Function TestIDE(Test As Boolean) As Boolean 
    Test = True 
End Function

[RickN]

Op woensdag 24 juli 2002 12:12 schreef johnwoo het volgende:
Probeer dit eens:

code:

Public Function InIDE() As Boolean 
    Debug.Assert Not TestIDE(InIDE) 
End Function 
Private Function TestIDE(Test As Boolean) As Boolean 
    Test = True 
End Function

Wow, als dit echt iets nuttigs doet is VB nog slechter dan ik al dacht, maar ik denk dat je ergens een foutje hebt gemaakt....

[johnwoo]

Op woensdag 24 juli 2002 12:22 schreef RickN het volgende:

[..]

Wow, als dit echt iets nuttigs doet is VB nog slechter dan ik al dacht, maar ik denk dat je ergens een foutje hebt gemaakt....

Nope, het werkt echt
Ik heb het trouwens niet zelf verzonnen hoor, maar Google doet wonderen

[edit]
Als reactie op RickN, nog even een uitleg wat er precies gebeurt (het is vrij logisch als je erover nadenkt )

De Debug routines zijn in een executable niet aanwezig. Dus als je het als exe draait is InIDE eigenlijk een lege functie, en retourneert dus de default Boolean waarde False.

Als je in de IDE draait moet InIDE True teruggeven. Iedere functie in VB heeft altijd een lokale variabele met de naam van de functie, waar je de return waarde naartoe kunt schrijven. Maar een Assert aanroep krijgt een expressie mee, geen statement. Je kan dus niet direct Debug.Assert InIDE = True doen, want dan controleert hij alleen maar of InIDE True is (wat niet het geval is en dus een break zou opleveren).
Daarom de extra hulpfunctie TestIDE. We geven de lokale variabele InIDE mee, die in TestIDE op True wordt gezet (de code werkt dus niet meer als je deze ByVal meegeeft). De return value van TestIDE blijft False; daarom de Not in Debug.Assert, anders zou VB breaken op dat punt. (In plaats van die Not zou je ook TestIDE True kunnen laten retourneren, maar dat is weer een extra regel )
In ieder geval staat InIDE nu op True en zal de functie InIDE dus True teruggeven

Tot zover de VB analyse

[tomato]

Wat jij beschrijft is niet het verschil tussen designtime en runtime

[johnwoo]

Op woensdag 24 juli 2002 12:30 schreef tomato het volgende:
Wat jij beschrijft is niet het verschil tussen designtime en runtime

Ow damn, inderdaad Dit fragmentje bepaalt het verschil tussen runnen in de IDE en als executable
Maar dat is wel wat de topicstarter wilde weten:

Als het programma via een exe gestart wordt, var = 1, als hij gestart wordt vanuit VB-IDE dan var = 0. Is dit mogelijk ?

De topictitel is dus incorrect...

[tomato]

johnwoo: Ow damn, inderdaad

Was eigenlijk bedoeld naar de topic-starter, jij gaf gewoon het antwoord dat hij wilde

De topictitel is dus incorrect...

En de eerste zin uit zijn post

[pkouwer]

wat is er dan precies fout aan, leg dat eens uit.
Als het progje loopt als zijnde een exe, dan is de var 1, in het andere geval is de var. 0

Makkelijker kan ik het niet maken (leuker wel)

[GigaTexel_BE]

ik zie ook soms Debug.Print

wat doet dit en waar zie je er de output van?

[Crazy D]

Op woensdag 24 juli 2002 20:05 schreef GigaTexel_BE het volgende:
ik zie ook soms Debug.Print

wat doet dit en waar zie je er de output van?

[url="http://msdn.microsoft.com/library/en-us/vbenlr98/html/vaobjDebug.asp"]Debug Object[/url]

The Debug object sends output to the Immediate window at run time.

[Verwijderd]

verschil tussen design time en runtime is . .. loopt mijn programma of niet . .. ik zie niet in hoe je zoiets moet kunnen 'zien' .. .want in design time.. . (oftewel . als je je programma nog aan het ontwerpen bent) dan loopt je programma nog helemaal niet . ..

het voorbeeld wat ik hierboven zie staan vertelt je of je in debug-mode zit . . of dat je in compiled-mode zit (heeft dus niks met runtime/designtime te maken)

[Verwijderd]

(oftewel . als je je programma nog aan het ontwerpen bent) dan loopt je programma nog helemaal niet

Jij hebt nog nooit met user controls gewerkt gok ik zo

[pkouwer]

ok. Ik wil het verschil kunnen zien of een prog nog in design-fase zit of dat het gestart wordt vanuit een exe.

Dat is toch niet moeilijk te begrijpen dacht ik zo...>:)

[Gerco]

Op donderdag 25 juli 2002 10:21 schreef Yarvieh het volgende:
Jij hebt nog nooit met user controls gewerkt gok ik zo

Dat is inderdaad een mooie, runnen in design time, VB zelf snapt het ook niet helemaal, als je een subclass hebt op een window schakelt VB steeds van running naar design, telkens als je de muis beweegt. Heel zenuwachtig gedoe kan ik je vertellen.

[johnwoo]

Okee, ik zal proberen het voor eens en altijd duidelijk te maken want er worden hier wat dingen door elkaar gehaald.

Een VB programma kan in drie fasen verkeren:
Designtime
Runtime - IDE (als je op F5 drukt)
Runtime - Executable (compiled)

Wat topicstarter wilde weten is het verschil tussen de laatste twee (runtime in IDE of als executable); dat is dus niet het verschil tussen designtime en runtime.

Dat verschil is over het algemeen niet zo interessant, behalve als je met UserControls werkt. Die worden namelijk ook geinstantieerd als jij ze op je form sleept in designtime; anders zou je UserControl natuurlijk geen UI kunnen tekenen terwijl hij op je formpje in de editor staat. Dus zelfs in designtime kan er code worden uitgevoerd in de IDE.

Ik hoop dat het nu duidelijk is

[edit] Gerco: inderdaad, telkens als er een message is voor je gesubclasste window schakelt VB heel even over naar Running om die message te verwerken. Ook als je je project saved krijg je dan wat geflits te zien
Ik dacht eigenlijk alleen dat VB mousemove (en wat andere) messages niet doorstuurde in designtime...

[pkouwer]

ok,ok.
Ik wil het verschil weten tussen de laatste 2. In IDE-runtime moet ik niet printen, via de exe wel. Duidelijk ?

[Gerco]

Op donderdag 25 juli 2002 12:10 schreef johnwoo het volgende:
[edit] Gerco: inderdaad, telkens als er een message is voor je gesubclasste window schakelt VB heel even over naar Running om die message te verwerken. Ook als je je project saved krijg je dan wat geflits te zien
Ik dacht eigenlijk alleen dat VB mousemove (en wat andere) messages niet doorstuurde in designtime...

Voor zover ik weet doet 'ie dat ook niet, niet de normale usercontrol_MouseMove enzo, maar je eigen WndProc zit VOOR de code die VB gebruikt om die events te 'vangen' (anders was het geen subclass), dus je WndProc wordt wel uitgevoerd, want VB komt daarna pas aan de beurt.

Ik moet zeggen dat ik het wel knap vind dat die IDE overschakelt naar running enzo, in principe is die hele IDE niet geschikt voor subclassing zooi, ik ben onder de indruk dat het uberhaupt de IDE niet per definitie crasht...

Ik heb een usercontrol gemaakt die zn parent window subclasst en dat gaat tot mijn opperste verbazing allemaal prima in de IDE

[johnwoo]

Op donderdag 25 juli 2002 16:51 schreef Gerco het volgende:

[..]

Voor zover ik weet doet 'ie dat ook niet, niet de normale usercontrol_MouseMove enzo, maar je eigen WndProc zit VOOR de code die VB gebruikt om die events te 'vangen' (anders was het geen subclass), dus je WndProc wordt wel uitgevoerd, want VB komt daarna pas aan de beurt.

Ik moet zeggen dat ik het wel knap vind dat die IDE overschakelt naar running enzo, in principe is die hele IDE niet geschikt voor subclassing zooi, ik ben onder de indruk dat het uberhaupt de IDE niet per definitie crasht...

Ik heb een usercontrol gemaakt die zn parent window subclasst en dat gaat tot mijn opperste verbazing allemaal prima in de IDE

Hehe, totdat je app een foutje maakt, dan crasht wel gelijk heel VB mee (daarom zijn projecten met subclassing zo lastig te debuggen )

[Sponge]

Check [url="http://www.pscode.com"]http://www.pscode.com[/url] Genoeg voorbeelden die met een div. by zero bepalen of je in IDE zit (of niet)

[Gerco]

Op donderdag 25 juli 2002 19:23 schreef johnwoo het volgende:
Hehe, totdat je app een foutje maakt, dan crasht wel gelijk heel VB mee (daarom zijn projecten met subclassing zo lastig te debuggen )

d0h!

Daar hebben ze bij MS een handig iets voor uitgevonden: dbgwndproc.dll (oid). Dan kun je veilig subclassen in de IDE, je kunt zelfs met de debugger door je wndproc heensteppen, en de stopknop gebruiken.