I chooses on hour, but when I am searching a way to do something, it can be several times per minute.
So, you choose the number of run using minutes / hours, depending on your code write speed
Hi Emily,
An interesting question 
Completed projects: During the workday - my completed projects run a minimum of 4 times per hour.
Xojo projects which are a ‘work-in-process’: At least 10 times per hour. Chuckle, this is usually to remove bugs and intentionally try and break the code. Using an analogy from the show Star Trek : To boldly go where no one has gone before
A lot different paradigm than 30 years ago
In the beginning we were trained to design our code, write our code, benchtest our code
and it had better run successfully the FIRST time.
Of course that was before the days of the desktop computer, and the “free limitless” access to CPU time
For those of you too young to have been there. When I worked for General Dynamics back in the 80’s. It cost my department $33.00 per SECOND of CPU time (CPU time was different that WallClock time)… and we had to account for EVERY cent.
[quote=65650:@Dave S]A lot different paradigm than 30 years ago 
In the beginning we were trained to design our code, write our code, benchtest our code
and it had better run successfully the FIRST time.
Of course that was before the days of the desktop computer, and the “free limitless” access to CPU time
For those of you too young to have been there. When I worked for General Dynamics back in the 80’s. It cost my department $33.00 per SECOND of CPU time (CPU time was different that WallClock time)… and we had to account for EVERY cent.[/quote]
[quote=65650:@Dave S]A lot different paradigm than 30 years ago
In the beginning we were trained to design our code, write our code, benchtest our code
and it had better run successfully the FIRST time.
Of course that was before the days of the desktop computer, and the “free limitless” access to CPU time
For those of you too young to have been there. When I worked for General Dynamics back in the 80’s. It cost my department $33.00 per SECOND of CPU time (CPU time was different that WallClock time)… and we had to account for EVERY cent.[/quote]
I bet it was on DEC machines? VMS? The company I worked for charged about $2.50 a minute. Ooh I miss my VT220…
Oh I don’t 
No… actually it was some IBM iron, and some mainframes made by I think it was Hitachi (that were clones of the IBM hardware).
I had an IBM3270 terminal on my desk.
I used DEC/VMS when I started (20 yrs ago) with the company I am currently with, but as result of many buy-outs and take-overs, we are now using AIX/Unix computers
I worked for AMEX, we had the 3270’s and later the IBM PC with a kind of hybrid extension board so it behaved like a PC or a terminal. Believed they called it a 3270 PC. Very expensive.
Attachmate wrote one of the first 3270 emulators for the early IBM PC.
I don’t recall exactly now… but I had to rewrite their entire keyboard mapping structure to support something that theirs did not do. I submitted it to Attachmate, and they later offered it as part of their upgrade package.
Yes! Attachmate. I recall KEA, a multi purpose terminal emulator. I do remember that you could put macro’s under a hotkey. I impressed collegues with a fully automated set of instructions, that is if you hit the key a the appropriate starting point. If not… Chaos.
Thank you all for yopur answers.
It does not bother you to have to click in the Code Editor to make modifications / Additions everytime you quit the compiled project (go back to the Code Editor) ?
[quote=65787:@Emile Schwarz]Thank you all for yopur answers.
It does not bother you to have to click in the Code Editor to make modifications / Additions everytime you quit the compiled project (go back to the Code Editor) ?[/quote]
What other expected workflow would you desire? Where (how) else do you propose to make modifications/additions if not in the code editor?
I think what @Emile Schwarz is getting at is that there is a fundamental (and extremely longstanding) workflow problem with keeping the debugger separated from the code editor.
Essentially, the question I always ponder on this topic is “Why can’t I just edit right in the debugger? Why is the debugger NOT using regular code editor functionality so that when I’m stepping through code and find an issue, I can just fix it right there?” In conversations with Norm at the last XDC some light was shed on the … uniqueness… of the debugger and why it must do things the way it does. Given that it has to be this way, my next question is since I have to hop back over to the editor to fix the issue I just identified in the debugger, why the heck can’t the “edit” button take me to the same line number I was on in the debugger?
Some of my methods get long - people will say that this is bad form, but it really does fit what I do… some functionality I write really is atomic enough to be a single method that takes several hundred lines of code to finish. Jumping from the debugger to the editor ALWAYS causes me a mental context switch and brief confusion while I try to figure out where I landed in the editor and where I need to go to fix the line I was just on in the debugger.
I hate to beat the “other environments” drum, but honestly - every other environment I’ve ever used (XCode, Aptana, Eclipse, etc) seamlessly integrates the debugging activities into the editor so there is no need to jump anywhere. Oh how I wish Xojo could do this as well.
As I understood Norm at the last XDC, getting there will require a complete rewrite of the debugger, which is a massive task with a lower priority than the other kajillion massive tasks they already have on their plate.
Well, in a way they are separate because you can go back into the code editor and change code whilst debugging. The debugger view is what is actually running. So if you allowed code to be edited in the debugger what should the debugger show if an exception is thrown but the code is no longer there? It’s a catch-22 then.
I could see making them the same view as being really confusing. More confusing than it is now? I dunno.
The main things I need to see when debugging are:
- What line of code is currently about to execute (in an editor would be ideal, as then I could identify issues and edit in-line)
- The contents of the stack, broken down by thread.
From the user standpoint, there is no reason that 1) should be read-only, with the caveat that the developer must understand any changes made there will not take effect until the next compile is completed. In my case, ANY time I make a change to the code, I automatically kill the debug session and run it again to ensure the change did what I expected.
The cycle I assume just about all of us go through is edit->compile->debug->edit->compile->debug, etc. I don’t think that allowing users to edit right in the debuggers code view would cause much if any confusion, or have people assume they can edit->compile->debug->edit->debug->edit->debug without compiling in there somewhere.
As for the stack, there is nothing special about the stack view that Xojo provides - it is below the view of the code that is being debugged and is clearly separate from the “code”.
I see the current debugger as a read-only code editor with a pretty limited stack view below it. Other debuggers I’ve used have been HUGELY more useful in terms of helping actually debug code, partly because they seamlessly integrate with the code editor and partly because the capabilities of the debugger are far greater: watch points, better stack navigation, real-time interaction (i.e., I can manually execute arbitrary lines of code to “play with” objects in memory in the debugger in XCode - such as manually calling specific methods on classes in memory while the debugger is paused on a breakpoint) etc.
But I digress to just whining at this point. Xojo knows their debugger is barely passable… but they don’t have enough engineering resources to do anything about it in the near future.
No, not that. I may not be crystal clear earlier.
Each time I ran the project and quit, I have to click in the Code Editor area to be able to make modifications to the code.
But, sometimes, for example, I comment code and run to know where the code have troubles (faster to debug).
I tried to press the Tab key, once, twice, thrice, it is boring as hell.
Also, earlier today, before I remove some PushButtons, I placed their code in the correct location in a ToolBar. Each time I went to the ToolBar.Action event, I had to search where to place the code (where is my Case "" entry where I want to paste the code.
Things like that exists anywhere / everywhere. You can loose your tab contents; the tab is still open / exists, but nothing exists in the navigator: close that tab and re-open the object you want in a tab
When you drop an image (but not only an image) in the navigator, it does not stay where you release your Mouse: most of the time it appears on top of the list (say if you loose your image folder target). If you release the mouse inside an image folder, the dropped image does appears at the top of the list when you release the Mouse elsewhere in the hierarchy)
In the original post, I was meaning to highlight That I have to make extra stuff (click if no selection, many Tab if I have a selection, etc.) to achieve my needs. Loosing time on things once here or then is one thing, but if you loose time to re-select lines nearly every time you run your project is really boring.
Of course, if English was my mother tongue, this would be easier for me; or if you all speak French 