I have to modify my app so it can run a different character set. The character set is one for the Sami languages. The normal way it's implemented is just as a different *font* (and a different keyboard layout). Somebody who e.g wants to do word processing in Sami keeps most of his Windows Western settings, and just uses this special Sami font. (He also uses a Sami keyboard layout, and a set of stickers with Sami characters for the keyboard keys, but that is not important.) The character set is like WinLatin (Windows Western) with some 8-bit characters different.

What I plan to do is make a Sami version of my app by just changing the font of all edit controls in my app to the Sami font. Then the Sami users can enter Sami data into the database. Everything else (captions, prompts, error messages, etc) will still be in Norwegian. My Sami users will accept that. (Fortunately there is no problem with the delimiter characters. They are not used in the Sami languages.) Now I have decided to be very smart and change the font with a promoted CREATE handler. The promoted handler checks a certain global flag (in a common variable) to see if the app is to be run in Sami mode or not. So I can still have *one* version of my app, and don't need to maintain one Norwegian version and one Sami version. The promoted handler works very well so far, except for popups. Some of my app's popups contain user data, and I'd like the popup window's edit table to have the Sami font too - but only when the app is run in Sami mode, of course. My promoted handler only works for windows belonging to

my own app. I think that is what I want, really, except for the POPUP window, which is in SYSPROG. I tried to make a special promoted CREATE handler for the SYSPROG POPUP window, but it didn't work.

Any ideas?

Given time I'm sure I can find some possible solutions, but since I have this very simple and elegant and maintainance free solution for the ordinary windows I'd like to have something similar for the popup window.

And instead of coming back to work on Monday morning starting from scratch I hope there'll be some ideas waiting for me on this list.

- Oystein -

Oystein,

I'm not responding with certainty here but I think your original solution should work, i.e. create a promoted CREATE event in SYSPROG that your POPUPS will call. What have you done to attempt to make this work? Did you recompile POPUP so it knows to call the promoted CREATE event?

Outside of this I would simply modify the Popup/Popup_Sub routines instead and put your code where the edittable has been created. That should definitely work for you. The only downside is remembering your changes in case Revelation ever submits an update on those routines.

dbakke@srpcs.com

SRP Computer Solutions

Don,

…Did you recompile POPUP so it knows to call the promoted CREATE event?

Duh. Thanks. I remembered with the other windows. I forgot with POPUP.

…modify the Popup/Popup_Sub routines… The only downside is remembering your changes in case Revelation ever submits an update on those routines.

I liked the promoted handler approach because I thought it would be immune to updates. But I guess if the Popup window itself is updated I'll have to recompile at least.

- Oystein -

Don,

There was a second reason my approach didn't work. The POPUP window belongs to SYSPROG, and my promoted CREATE handler is for my app REGIMUS only. I didn't really want to make a global or SYSPROG CREATE handler. I wanted to limit the damage if something went wrong.

Any suggestions are welcome. I'm only half recovered from a bout of flu.

- Oystein -

Oystein,

I think my best suggestion is to make a local copy of the POPUP window in your REGIMUS application. That way it can be compiled with your application specific promoted events.

dbakke@srpcs.com

SRP Computer Solutions

Don,

Can I make a local copy of the POPUP window in my REGIMUS application and keep the window name ("POPUP")? I've tried making local copies of stored procedures earlier, and to get it to work I had to edit SYSENV*SYSPROCNAMES. Is there something special I have to do with windows too? Now I have just done a copy_row "SYSREPOSWINS", "SYSPROGPOPUP", "SYSREPOSWINS", "REGIMUSPOPUP", but I cannot access the new REGIMUSPOPUP window from Form Designer in REGIMUS. This might be trivial stuff, but please bear over with me. - Oystein - </QUOTE> —- === At 12 NOV 1999 09:10AM Don Bakke wrote: === <QUOTE>Oystein, This is much simpler than you think, although you need to first undo what you have already done. From the Exec line do a RUN DELETE_ROW so there is no trace of POPUP in the REGIMUS application. Next, simply open your Form Designer in REGIMUS and open the POPUP window. You will get the message that this is an inherited form. Then simply do a Save As and give it the same name. This will automatically create a copy of the window locally in REGIMUS and you can make any changes you like. BTW, the reason your first method didn't work was because you didn't create a Repository record for your window. dbakke@srpcs.com SRP Computer Solutions </QUOTE> —- === At 12 NOV 1999 12:39PM Oystein Reigem wrote: === <QUOTE>Don, Thanks again. I knew it was something really simple. I must have done this once earlier. But this time that message "Replace existing POPUP?" for some reason made me think I messed with the original in SYSPROG. What you say about the repository record certainly crossed my mind, but since I was so convicted the whole thing should be very simple I just didn't follow that direction. - Oystein - </QUOTE> —- === At 12 NOV 1999 01:21PM Oystein Reigem wrote: === <QUOTE>Don, It's trickier than I thought. My promoted handler (that sets the font of the edit table in the POPUP window) does run later than a lot of other handlers, but the wicked window has a SYSPROG*STPROCEXEPOPUP_SUB quickevent that runs even later. And sets the font back.

I tried to do a Forward_Event in my promoted handler, to get the quickevent to execute earlier, but it doesn't seem to change a thing. Do you think it ought to work?

If there isn't an obvious solution I guess the next alternative is to forget the promoted strategy for the POPUP window and rather make a local version of procedure POPUP_SUB.

- Oystein -

PS. In the other posting I said I was confused by the "Replace existing POPUP?" message. Compare that message to the one you get if you try to do the same thing with a stored procedure: "You are about to compile a procedure owned by the 'SYSPROG' application and place the source and object code in the '' application! Are you sure you want to do this?" Now that's a message that cannot be misinterpreted! 1-0 to the author of System Editor!

Oystein,

It seems to me that forwarding the event should work. Are you returning 0 so it doesn't call the QuickEvent CREATE again?

I'm sure you are getting the overwrite message because you have not deleted the first window you attempted to copy via the Exec line. I believe I suggested deleting that first.

dbakke@srpcs.com

SRP Computer Solutions

Oystein,

Something else I forgot to ask: why don't you just you the TypeOveride parameter to specify the font in the PopUp function? Or are you calling it via the Repository function instead?

dbakke@srpcs.com

SRP Computer Solutions

Don,

Because I wanted to have a general clip-on solution and not having to change every single Popup call in my app. And yes - I do use Repository a few times too.

About your other posting: I'll have to check more when I'm back at work on Monday. But System Monitor seemed to tell me there were no change in the order the events were executed. At least it listed the quickevent only once, so I don't think it's the "return 1" problem.

Thanks for your patience and have a nice weekend!

- Oystein -

Don,

Please help.

I now have

(1) one promoted handler REGIMUS*CREATE..OIWIN*

(2) a commuter function Promoted_Events that is called by the promoted handler (I have plans for additional promoted handlers)

(3) a couple of windows that need the promoted handler.

I maintain the promoted handler in a stored procedure. Whenever I change the handler I copy the compiled version to SYSREPOSEVENTEXES and recompile all windows that use the handler.

Today I discover the changes I make to my promoted handler don't take effect. There seems to be an old version that runs. In the System Monitor log I can see a call to Forward_Event that I removed many compilations ago. I also removed the call to Promoted_Events many compilations ago, and Promoted_Events is still called. Changes to the Promoted_Events function do take effect.

There is one thing I can do to the promoted handler that does have consequences, and that is to remove it completely (run Delete_Row "SYSREPOSEVENTEXES", …). Then it doesn't run. At least Forward_Event and Promoted_Events are not called. But as soon as I copy the compiled handler in again, it's back to abnormal.

I'd been at my wits end now, had I not suspected there's a trivial explanation.

- Oystein -

PS. I'm aware of the return 0/1 stuff.

View this thread on the forum...