Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Number formatting
Hi,
In SRP reporttable we want to display valuta in a column and also make it sortable . For US we can use #,##0.00 for format and the valuta are displayed US-style. In The Netherlands we should use #.##,00 In excel this works fine but in the srp edittable 1234.56 gets formatted as 1,234.5600. We think the srp edittable ignores the windows country/region settings?
What can we do to correct this?
Regards Ed Keeman
In SRP reporttable we want to display valuta in a column and also make it sortable . For US we can use #,##0.00 for format and the valuta are displayed US-style. In The Netherlands we should use #.##,00 In excel this works fine but in the srp edittable 1234.56 gets formatted as 1,234.5600. We think the srp edittable ignores the windows country/region settings?
What can we do to correct this?
Regards Ed Keeman
Comments
Dates work fine already.
It is only the punctuation for numbers you have to address we think.
OInumber = 1234.56
Output in reporttable shows 1.234.5600
expected output = 1.234,56
We get 4 decimals with this formatting: #.##0,00
OInumber = 1234.56
Output in reporttable shows 1.234,5600
expected output = 1.234,56
Also note that if you use $ in your number format (without quotes), it will use the localized currency on final output.
In version 4.1.19.5 when we double-clicked some row then that row would open.
In version 4.2.0.5 the top-row opens.
The version historie gives us no clue.
We see that the first (left) click fires a double-click only the first time the window was opened.
Looks like the same issue we have with the edittable.
I was playing around with 4.2.0.5 and saw something maybe similar RE different behavior in the beta. I have a SRP Button that has code to fire OnClick. It stopped working.
Long story short it looks like the only Event with the beta controls was a GotFocus (apart from OnMouseOver and OnMouseExit) and I had no code for that..
Reverting the Controls and restarting my OI and I was back with the expected OnClick.
I have observed this behaviour in both of our 9.4.6 OI systems, iTMS (no SRP Framework) and Opto (SRP Framework).
The iTMS version of this Form if basically the Opto version retrofitted (we do this in a couple of special cases that you might be familiar with since I believe you helped us create them! In this case it is the MYOB Export form).
It has these extra lines in the CREATE that OPTO does not have, plus a few other things.
// Qualify all events Send_Message(@Window:".OLE_RIBBON", "QUALIFY_EVENT", "ALL_OLES", 1) SRP_Redirect_OLE_Events()I will, however, concentrate on Opto though. It is the more nomal, Commuter driven, process for us.
I have a form (with OLE_SUBCLASS control) that has an SRP Button
At the top of my Commuter I dropped a debug to capture the events for my test button.
If Control EQ "OLE_INVOICE_REFRESH" then debugResults - Events noted:
Original SRP Control (4.1.21.1)
- OnMouseEnter
- OnClick (with some params being passed in)
- OnMouseExit
(After the first test, I closed fully closed OI. UnRegistered the control. Changed the Control. Re-Registered the control. Restarted OI. This was the only change)New (4.2.0.5)
- OnMouseEnter
- GotFocus (not OnGotFocus)
- OnMouseExit
Debug ValuesPROGID = SRP.Button.1
MDIFrame = FW_MAIN
PARENT = FW_MAIN.MDICLIENT
Thats at least some paint on the canvas...
(After the first test, I closed fully closed OI. UnRegistered the control. Changed the Control. Re-Registered the control. Restarted OI. This was the only change)
Send_Message(@WINDOW:".OLE_INVOICE_REFRESH","QUALIFY_EVENT","OnClick",1)to the CREATE with no joy.BTW, I thought thats what the SRP_Redirect_OLE_Events() was to do? I stepped through that and it definately sent a QUALIFY_EVENT for "ALL_OLES" for the Control in question.
So I tried this in iTMS as its behavior is a little different. Not sure about the reasons under the hood but the Event that we capture in SRP_Controls v 4.1.xxx is "OLE" and Param1 = 'OnClick'. We intercept that Param and pass it through as the 'Event'. This works in the 4.1 Control (as I put in a debug in the GoSub) but it does not fire in the 4.2 Control with no other changes.
Ad the top of my commuter I can intercept this in 4.1.x:
If Control EQ "OLE_INVOICE_REFRESH" AND Param1 _Eqc "OnClick" then debugIn 4.2.x neihter of these work (even when qualified):
If Control EQ "OLE_INVOICE_REFRESH" AND Param1 _Eqc "OnClick" then debug If Control EQ "OLE_INVOICE_REFRESH" AND Event _Eqc "OnClick" then debugWe are at 9.4.0
Most of our windows are mdi-children.
We do use promoted events.
We just found out that the issue is triggered when a row in the control was clicked when it has no has no focus .
We made a form with a button and a reporttable with some rows.
We start the form as a mdi-child.
When we click the button the reporttable looses focus.
We single-left-click on a row and then the OnItemDblClick is fired.
This test reproduces not exactly the problem because SELPOS changes to the clicked row.
In production we see that SELPOS was not changed to the clicked row in the OLE Event "OnItemDblClick"
We hope this information helps...
I was originally using the file you linked here which is when I discovered issues in my iTMS system a couple of days back. I thankfully didnt have the range of issues keeman's users reported but I did have a user note a function 'not working' correctly. It was easy for me to track down as the Controls was literally the only thing changed there for months so I maybe rolled that back before other issues presented themselves.
Unfortunately, all the examples I included yesterday were running the production release using the installer executable (not just an ocx copy-in and re-register like I did for the beta.) I had installed that straight away when I saw the Blog entry of goodies to see if my issue still occurred.
Like keeman, I have reverted to 4.1.21.1 for now. I also think I will follow his lead and try and create a minimalist 'clean' example rather than concentrate on existing functionality.
We installed the version from the products-website.
We see the same behaviour.
We created the test-window in SYSPROG
No promoted events in SYSPROG
We also included SRP.EDITTABLE in the test
We test-run the window from FORMDES. (not as mdi-child)
The issue is triggered when a row is left-single-clicked while the window has no focus both for EditTable and ReportTable.
For the (known) issue with EditTable we made a work-around in the promoted events but it is still there.
Regards Ed
Yesterday and prior, I could toggle my issue quite easily in my existing form, in multiple systems, by just changing the OCX.
When I went to create a new minimal example, it worked as expected with the new Controls.
I then took my existing form and cut it down (keeping the entire 'header' and Create event in the Commuter and stripping out all other Controls from the form). Worked as expected!
Going back to my original form it now works as expected on 4.1.21.1, 4.2.0.5, 4.2.1.0!!!
Frustrated to say the least.
Its no wonder you couldnt replicate it Kevin, I can't either any more.
BTW, I apologise to keeman for hijacking his thread a bit. I thought at the start there might be similarities in our issues related to Events in the new Controls... Now I dont know what to think.
Ed, I don't waste anymore of you time trying to recreate the issue on my end. I've created a dropbox request. If you are okay with it, you can zip up your OI app and send it me. Let me know what form to run and I'll hopefully be able to isolate the issue much faster.
Qualifying events as synchronous is only useful for certain events. In SRP Frameworks, these are the only events we qualify synchronously because they allow the programmer to cancel the action:
SRP EditTable
BeforeDeleteRecordsBeforeInsertRecords
BeforeNewRecords
BeforeUpdate
OnInvalidData
PosChanging
SRP Tree
BeforeUpdateOnDragStart
I anticipate that your response might be that this works in prior versions, and you'd be justified in being upset that this requires a change on your end. To that I would say that I am still investigating a way around this, but after spending hours on this, I have yet to find a resolution. I don't want to keep you waiting, and I want to urge you to update your system to not be using synchronous events unless necessary and especially not to use ALL_OLES. OLE events have a lot of overhead, so they should only be qualified as needed.
So why did this work before? The answer is simply good fortune. Synchronous OnGotFocus events have always been unstable. A house build on sand, so to speak. The SRP ReportTable uses CodeJock's Report Control, and I had to upgrade to their latest codebase in order to add DPI support in 4.2. This upgrade came with behavioral changes that exacerbated the already fragile synchronous OnGotFocus event issue.
I know this is isn't the reply you hoped for, but I hope it's a helpful one. If I find a fix, I will let you know. If you choose to stay in 4.1.21.x, I'll understand.
We are glad you found out why our SRPControls don't work as expected.
Qualifying of events happens in one peace code in our application.
That's why we use "ALL_OLES".
Earlier we tried asynchrone for all events but that messed things up.
We are going to tune the events and follow the SRP Framework way.
Why isn't this "Best practice" in your documentation?
Hopefully we will be soon at 4.2
Regards Ed Keeman
That is a fair question. For one, this only became best practice as of OI 9.x. Our controls have been around since OI 4 and we still have clients using OI 8 and our controls. Originally using ALL_OLES was best practice. Second, I don't think we see many people using ALL_OLES (or ALL_WINMSGS for that matter) so it just didn't occur to us to document it. Most of our FrameWorks customers upgrade FrameWorks periodically. When they do, they get our updated method for qualifying events.
I think the real answer is that the documentarians are also the programmers. Our refinements happen in tiny adjustments over short slack conversations, then we get back to work. It's not our intention to keep customers in the dark.
Just a tip, helping the community.
In the Schedule control are also some events that can be canceled, so we made them synchronous.
Just use the eventname.