›
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

keemankeeman
in SRP ReportTable Control
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
«1

Comments

  • KevinFournierKevinFournier
    You're right, that is currently not supported. I'll make this a high priority item as it's a long overdue oversight that should be remedied as soon as possible. Give me some time, though, as adding locale support to all formatting options is a lot.
  • keemankeeman
    Most formats work for any locale.
    Dates work fine already.
    It is only the punctuation for numbers you have to address we think.
  • KevinFournierKevinFournier
    You can try this beta build of 4.2 and let me know if it formats correctly.
  • keemankeeman
    We get 4 decimals with this formatting: #.##0,00
    OInumber = 1234.56
    Output in reporttable shows 1.234.5600
    expected output = 1.234,56
  • keemankeeman
    Oops. Typo in previous message, lets try again...
    We get 4 decimals with this formatting: #.##0,00
    OInumber = 1234.56
    Output in reporttable shows 1.234,5600
    expected output = 1.234,56
  • KevinFournierKevinFournier
    The idea was that you only have to set the format once using en-US standards and the controls would automagically localize it for you. Try "#,##0.00" instead and see if that works.

    Also note that if you use $ in your number format (without quotes), it will use the localized currency on final output.
  • keemankeeman
    Yes, then it works. Thanks
  • keemankeeman
    We went from version 4.1.19.5 to 4.2.0.5 and see different behaviour in reporttable.
    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.
  • Opto_WillOpto_Will
    Maybe loosely related...

    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.
  • KevinFournierKevinFournier
    I'm not able to recreate either of these symptoms using 4.2.0.5. What version of OI? Are these forms MDI children or regular forms? Are there promoted events involved?
  • Opto_WillOpto_Will
    @KevinFournier, let me start to paint a picture then!

    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 debug

    Results - 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 Values
    PROGID = SRP.Button.1
    MDIFrame = FW_MAIN
    PARENT = FW_MAIN.MDICLIENT




    Thats at least some paint on the canvas...
  • KevinFournierKevinFournier
    Are you re-registering the OCX when you switch?
  • Opto_WillOpto_Will
    Yew.

    (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)
  • KevinFournierKevinFournier
    Sorry. This is what I get reading too fast. What happens if you just qualify the OnClick event? Debugs will absolutely interfere with the event chain because they cause the mouse and focus to change in the middle of something like an OnMouseEnter.
  • Opto_WillOpto_Will
    I added a : 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 debug

    In 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 debug
  • keemankeeman
    Hi Kevin,
    We 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...
  • keemankeeman
    We just went back to srpControls version 4.1.19.5. Users report problems like program stops working, forms closing spontaneously, typing not possible, documents don't open, etc.
  • KevinFournierKevinFournier
    I am still struggling to recreate these issues. I tried various environments. Are you guys still using the OCX I linked here? If so, can you download the latest from our products website and see if the issues persist? If they do, then I'm going to need a copy of your systems to see what's going on, but we'll cross that bridge when we get to it.
  • Opto_WillOpto_Will
    @KevinFournier.

    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.
  • keemankeeman
    Hi Kevin,
    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
  • Opto_WillOpto_Will
    Update.

    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.
  • KevinFournierKevinFournier
    These are the worst kinds of bugs to track down. The fact that things suddenly are working is not proof that there's not a problem. It's possible, though, that the issues are not related.

    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.
  • KevinFournierKevinFournier
    Ed, I know what is causing your issue. You are qualifying all events as synchronous, which includes the OnGotFocus event. Not only do you get the unwanted OnItemDblClick, but did you notice the unwanted OnLostFocus events too? When OnGotFocus is synchronous, OI misbehaves.

    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

    BeforeDeleteRecords
    BeforeInsertRecords
    BeforeNewRecords
    BeforeUpdate
    OnInvalidData
    PosChanging

    SRP Tree

    BeforeUpdate
    OnDragStart

    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.
  • keemankeeman
    Hi Kevin,
    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
  • DonBakkeDonBakke
    Why isn't this "Best practice" in your documentation?

    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.
  • KevinFournierKevinFournier
    You mean this? Just kidding... I just added it.

    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.
  • keemankeeman
    It was no criticism.
    Just a tip, helping the community.
  • KevinFournierKevinFournier
    We appreciate the tip. I hope the new documentation provides some insight on how (a)synchronous event handling affects timing.
  • keemankeeman
    OLE-events should be registered with OLE.[Eventname] ,.
    In the Schedule control are also some events that can be canceled, so we made them synchronous.
  • AusMarkBAusMarkB
    You don't need the "OLE.".

    Just use the eventname.
Sign In or Register to comment.