It's not necessary to disable the Table. Lots of other people have used it for several years without finding the need to do so. Basic4ppc is a single threaded .NET process. All code runs on the GUI thread and the message loop is only re-entered when the code terminates so there is no possibility of re-entrancy.
There are only two occasions when re-entrancy to a Basic4ppc event Sub can occur. Firstly if the Sub calls DoEvents which in turn calls the message loop to process outstanding messages, and secondly if the event Sub raises a MsgBox as the message box pumps the message loop to get its GUI events. Timers cannot cause re-entrancy as they are run on the GUI thread in response to messages received on the message loop. I know of no other thing that can cause re-entrancy in normal Basic4ppc code and I know quite a lot about Basic4ppc internals and re-entrancy as my Threading library will work in both the interpreted IDE as well as when compiled.
__________________
Sorry, but I don't answer questions by PM or email.
Please post your queries in the forum.
I wasn't just thinking of recursion by re-entry. It can happen mutually too (via two event handlers). But if anything recurs that is a worst case. You can still get unwanted events. That is more common and just as much a nuisance.
Take my full source. Put breakpoints on the first code lines (if statements) of Sales_SelectionChanged and SalesCell_ValueChanged. Now run. Select the Sales tab. You will now hit the first breakpoint. Press F10. It takes you back to a line in Tabs_SelectionChanged. The line above is the culprit a call to SelectCell. I only want user selections to cause any processing, so it is essental to trap this.
F5. Click the button This. You now hit the second breakpoint. F5 till it runs again.. Select the top left cell. F5. Spin the spinner up 1. F5. Now select the empty cell in the middle of the top line. 1st bp. F5 and we are where? Second bp. F10. The lines above show that the assignment to Value is the culprit. Again processing is not required at this time, only when the user does it.
So, two jumps from Event Handler to Event Handler. In other words a message being generated and handled whilst a first message is being handled. Given what you just said about B4PPC, that implies a DoEvents inside these controls? Yes/no/maybe?
I tried taking out the first breakpoint to see if selecting a cell under Start on a lower row did anything. Sure enough, I ended up at the second bp. So I wasn't being mislead by the fact of using the debugger which might have been a cause of the program being stopped and therefore eligible for message processing.
Whatever, without going through the whole proggy, just trust me when I say for all cases in this program, programatic changes are not required to cause processing, only those made by the user are to be processed. That wasn't happening, I had to force it to happen.
But remember, the real use of disable is to stop user interaction during slow processing. You have to see my old laptop when my flakey wireless connection is playing up. You could play a game of speed chess sometimes! Other systems are nowhere near as bad, but they still have their moments. The use of disable as a flag is just piggy-backed on top of that. Two birds with one stone and all that.
Incedently, some of the program complexity was caused by only having a ValueChange event for the up/down control. It would have been simpler with the SpinUp/SpinDown events seen in other environments as there are differing types of end conditions to cater for.
So, two jumps from Event Handler to Event Handler. In other words a message being generated and handled whilst a first message is being handled. Given what you just said about B4PPC, that implies a DoEvents inside these controls? Yes/no/maybe?
No. Not all events are necessarily triggered by a call from the message loop. One message being processed can cause another call directly to other Windows Procedures, most commonly by a native code SendMessage API call within the message processing code, which in turn raises a Basic4ppc event. But all the code is being run sequentially on the main GUI thread of the application without interruption (apparently! as obviously the system is time slicing all the time but a single process is unaware of this - and let's not get into the threading tricks the .NET Garbage Collector does to ensure safe checkpointing of CLR code so it can reclaim unused memory, it's very interesting, nay fascinating, but a bit arcane).
__________________
Sorry, but I don't answer questions by PM or email.
Please post your queries in the forum.
Well, yeah, SendMessage was always the standard way of blowing the basic loop model.
Basically, however it is done underneath, the Events model user sees events which give the appearance of being interruptable by other events because no direct call is made by the user, regardless of whether the lower system sees it as not being an interrupt.
***************
Just to give an insight, this app is to be used on a small preserved railway with just two stations. I've been doing the same thing on the laptop using a separate app for the price setting part in Delphi and the rest in an Excel spreadsheet which had lots of controls, but could also be used as the Ticket Returns form, by hiding everything and printing the basic layout. The app went to meetings, the sheet to the ticket office.
Then I transfered the app to the mobile pc by rewriting in B4PPC as this was more convenient for me to take to meetings (less to carry; longer battery life). And there it should have rested. But now I can't lift things for any distance, so I want to do it all on the mobile pc or a phone, I can always write out ticket forms manually later from the collected data. Less convenient but needs must.
Some of the non-standard requirements that other B4PPC users won't have is for example, tickets are numbered with 4 digits, so you have to handle the day the numbers wrap around. Also, to allow corrections of mistakes in tickets sold, the spin down not only has to stop when you get down to your starting number (ie 1 sale) but also has to go blank for 0 sales, otherwise it gets seriously confusing having meaningless numbers displayed. And of course depending on where you've got to in day and the initial options, some things have to be selectable on the tables some of the time but not others. Other items are never input but are calculated despite appearing on the same table as input items. The displays would fragment (visually) too much were this not so.
So that's what all the "ess aitch one tee" in the app is about and why it is not entirely as other apps. But the individual little bits are all trivial, there's no complex computing, the complexity lies in controlling what the user can do and what he sees, which needs being accurate, complexity is really the wrong word.
Hope that helps.
*************
But anyway, we are (ok I am) off topic. The basic problem is this inconsistency inside the table control. I don't know from where I'm sitting whether that is how it is wrapped by B4PPC or an effect of .net. I've not seen this problem with grids not living with .net, but that may not prove much.
OK, I know when I'm beat. Even if that gets reported to MS, it will be ages before we see a fix, so I've changed the code. Access to critical events is now controlled by a global boolean and I only use Enable where it absolutely has to be used.
As agraham reported in post #8, when a cell is accessed after the enabling the table scrollbars are enabled.
So you could use this workaround to make your code running as you expected.
Hah, I could yes, but it reminds me of the time I deliberately put a NOP instruction into an assembly code module with a comment do not remove. I didn't say why as I figured anyone who was dumb enough to ignore the warning deserved the extremely obscure multi-task timing bug it fudged around. One of those is enough for one lifetime
Linear Mode
