To my mind one of the longest-standing mysteries in OpenInsight has been the purpose of the "Dialog box" checkbox in the Window Properties dialog as you can see here:
For years the function of this checkbox has eluded me (and my erstwhile colleagues), so much so that I believed it was simply something that the original Rev programmers intended to use but never implemented.
Well, after some recent work with the Revelation crew I came across the answer, and it's really simple:
It's used by the Repository( "EXECUTE" ) method for launching a window - if it's checked then the Repository function calls the Dialog_Box() function to execute the window instead of the normal Start_Window() function.
Mystery solved!
For years the function of this checkbox has eluded me (and my erstwhile colleagues), so much so that I believed it was simply something that the original Rev programmers intended to use but never implemented.
Well, after some recent work with the Revelation crew I came across the answer, and it's really simple:
It's used by the Repository( "EXECUTE" ) method for launching a window - if it's checked then the Repository function calls the Dialog_Box() function to execute the window instead of the normal Start_Window() function.
Mystery solved!
Labels: Form Designer, OpenInsight, Repository
Here at Sprezz Towers we're hard at work on the Big Project: a large Arev to OI conversion using our shiny new promoted event framework (well it ain't that new but it gets more polished each time we use it). Part of this week's programming fun has been implementing Arev Softkeys functionality as a menu that dynamically configures itself based on the active MDI child - we have a promoted event that simply alters a static "placeholder" menu on the fly using a combination of properties such as VISIBLE, ENABLED, TEXT and so on.
Visually all this was working really well, but as I waded into event handling I came across an unexpected problem: No events for the softkey menu items would fire! Hmm...
First of all I decided to check if the MDI frame was actually being told by Windows about the menu click: The trusty Microsoft Spy++ tool soon revealed that the frame was indeed receiving the menu item's WM_COMMAND message, but still nothing was getting to OpenEngine. This was really strange as normally ALL menu items call the RUN_EVENT function to see if there's a MENU event handler to execute - this time there was no action whatsoever.
Next I started turning off the Set_Property calls one by one to see if I could determine if any particular property was responsible for the strange behaviour and I came across an interesting result: As soon as I set the ENABLED property to FALSE$ the menu item lost the ability to execute a MENU event, even if I re-enabled it by setting ENABLED back to TRUE$.
This had me stumped at first until I tested some more and removed the code setting the VISIBLE property: If I didn't use the VISIBLE property then ENABLED worked as advertised. Progress of a sort I guess...
More testing revealed this: If I removed a menu item by setting it's VISIBLE and ENABLED properties to FALSE$, in that order, and then I subsequently set the VISIBLE and ENABLED properties back to TRUE$, again in that order, then the menu item's event handling stopped working. So, the next question was ... Why?
The evidence suggested that the ENABLED property did something different based on whether or not a menu item was hidden. A little more work with Spy++ showed that a hidden disabled menu item still raised a WM_COMMAND message when fired (via an accelerator key combination), but RUN_EVENT wasn't called. However, if the menu item was visible and disabled no WM_COMMAND message was raised. Ergo the menu ENABLED property must trigger a switch inside OpenInsight that turned off hidden menu item event handling.
Thinking about this some more led me to the following conclusions:
Indeed there is, and it's even there on a checkbox I totally ignore when designing menus in the Form Designer:
You can actually turn off menu item event processing by design and it's this flag that the ENABLED property is setting when you use it with a hidden item. The actual OpenInsight bug is that the flag is never set or removed if you use the ENABLED property on a visible item!
In other words, if you disable a hidden item you must re-enable it before you make it visible again if you want it to fire events.
So, armed with this new wisdom it was a simple matter to ensure that the ENABLED and VISIBLE properties were set in a better order, and now event handling works like a charm - another case closed!
Visually all this was working really well, but as I waded into event handling I came across an unexpected problem: No events for the softkey menu items would fire! Hmm...
First of all I decided to check if the MDI frame was actually being told by Windows about the menu click: The trusty Microsoft Spy++ tool soon revealed that the frame was indeed receiving the menu item's WM_COMMAND message, but still nothing was getting to OpenEngine. This was really strange as normally ALL menu items call the RUN_EVENT function to see if there's a MENU event handler to execute - this time there was no action whatsoever.
Next I started turning off the Set_Property calls one by one to see if I could determine if any particular property was responsible for the strange behaviour and I came across an interesting result: As soon as I set the ENABLED property to FALSE$ the menu item lost the ability to execute a MENU event, even if I re-enabled it by setting ENABLED back to TRUE$.
This had me stumped at first until I tested some more and removed the code setting the VISIBLE property: If I didn't use the VISIBLE property then ENABLED worked as advertised. Progress of a sort I guess...
More testing revealed this: If I removed a menu item by setting it's VISIBLE and ENABLED properties to FALSE$, in that order, and then I subsequently set the VISIBLE and ENABLED properties back to TRUE$, again in that order, then the menu item's event handling stopped working. So, the next question was ... Why?
The evidence suggested that the ENABLED property did something different based on whether or not a menu item was hidden. A little more work with Spy++ showed that a hidden disabled menu item still raised a WM_COMMAND message when fired (via an accelerator key combination), but RUN_EVENT wasn't called. However, if the menu item was visible and disabled no WM_COMMAND message was raised. Ergo the menu ENABLED property must trigger a switch inside OpenInsight that turned off hidden menu item event handling.
Thinking about this some more led me to the following conclusions:
- When a menu item is visible OpenInsight can use the Windows API EnableMenuItem function to disable it - the menu item is "grayed out" and clicking on it produces no WM_COMMAND message.
- When a menu item is hidden it is actually deleted from its parent menu - Windows knows nothing about it and therefore EnableMenuItem can't be used. However, OpenInsight still keeps the item details in memory so that hidden items can be executed via accelerator keys, so there must be a mechanism to disable this as needed.
Indeed there is, and it's even there on a checkbox I totally ignore when designing menus in the Form Designer:
You can actually turn off menu item event processing by design and it's this flag that the ENABLED property is setting when you use it with a hidden item. The actual OpenInsight bug is that the flag is never set or removed if you use the ENABLED property on a visible item!
In other words, if you disable a hidden item you must re-enable it before you make it visible again if you want it to fire events.
So, armed with this new wisdom it was a simple matter to ensure that the ENABLED and VISIBLE properties were set in a better order, and now event handling works like a charm - another case closed!
Labels: Menu, OpenInsight, Set_Property
The Rev community probably won't be aware of this but this month we're running an advert for Sprezzatura in a "mostly small business" magazine here in the UK. We figure that small business owners are sufficiently independently minded that they'll be able to see the benefit of custom software over commercial off the shelf software that still needs heavy customisation but costs ten times as much.
The target market place is sophisticated so we don't want to hit them with reams of copy - rather we want to appeal to their innate good sense. You don't as a rule get to grow a small business by being stupid. So the advert we came up with is reproduced here :-
We thought (and fought) long and hard about it internally and were pleased with the end result. The advert was due to go to press on September 1st. Today (September 3rd) we received an email addressed to info@sprezzatura.com from a gentleman who wanted us to fit him in for an appointment to tailor a suit for him.
We were mortified. Adverts aren't cheap and to think that we might have so misjudged it that people thought we tailored bespoke suits?
A flurry of investigation followed and one of our smarter members noticed that the person asking for the tailoring might have a Canadian presence as their company was present there. A couple of clicks in a browser and the answer was apparent. There exists in Canada a bespoke tailors with a website of www.sprezzatura.ca. It has existed for quite some time BUT the first time in our existence we get a tailoring query is two days after our "bespoke" advert went to press....
Of course with hindsight if it went to press two days ago it is unlikely to be in the wild yet so the chances of the mail being in response to our advert is 0% but hindsight is always 20/20!
The target market place is sophisticated so we don't want to hit them with reams of copy - rather we want to appeal to their innate good sense. You don't as a rule get to grow a small business by being stupid. So the advert we came up with is reproduced here :-
We thought (and fought) long and hard about it internally and were pleased with the end result. The advert was due to go to press on September 1st. Today (September 3rd) we received an email addressed to info@sprezzatura.com from a gentleman who wanted us to fit him in for an appointment to tailor a suit for him.
We were mortified. Adverts aren't cheap and to think that we might have so misjudged it that people thought we tailored bespoke suits?
A flurry of investigation followed and one of our smarter members noticed that the person asking for the tailoring might have a Canadian presence as their company was present there. A couple of clicks in a browser and the answer was apparent. There exists in Canada a bespoke tailors with a website of www.sprezzatura.ca. It has existed for quite some time BUT the first time in our existence we get a tailoring query is two days after our "bespoke" advert went to press....
Of course with hindsight if it went to press two days ago it is unlikely to be in the wild yet so the chances of the mail being in response to our advert is 0% but hindsight is always 20/20!
Labels: humour
| Making Databases Happen |
UK +44 (0) 20 8912 1010 USA +1 267 238 3814 |