F1 in editor causes CR.LF, not HELP

MARTINDRENOVAC

I have 2 devel environments on laptop
open editor
press F1 on 1st - works pefectly - > gives me help
press F1 on 2nd session - inserts CRLF at cursor
Ok, use Help/Help - does same, insert CRLF

I've reinstalled 8.2 into this bad environment - same issue

I can't locate difference in setup between the 2

DonBakke

Martin,

Just to confirm that you did not a bad install, can you please click on Help > About in both development environments and post the screen shots to this thread?

MARTINDRENOVAC

The rc3 has the issue

DonBakke

Martin,

That tells me you have two different builds in your environment. I recommend downloading the SRP Editor from the product site and re-install in all environments. Then double-check to make sure you don't see any RC# (release candidate) build numbers.

MARTINDRENOVAC

ok, done. Nothing's changed - one system inserts F1 as per prior notes.
including when I press F1 on the HELP/HELP

KevinFournier

Are these both copies of the same application? If not, is the offending application using promoted events?

MARTINDRENOVAC

these are the same code, albeit two slightly out of sync copies
the OI editor++ in the working system - F1 works and gets help
in the non-working system, when a piece of text is selected and i press F1 or use the menu - it does nothing, however it does not put in a 0D0A either

KevinFournier

I simply can't explain the 0D0A behavior. There is nothing being changed on F1. All it does is get the selected text, place it into a URL, and do a shellexecute "open" on it. If you don't have promoted events, then why are the about boxes colored? If you do have promoted events, please make sure they are skipping all windows that begin with "SRP_". This is what FrameWorks does, to avoid our stand alone tools running into troubles.

MARTINDRENOVAC

the boxes being coloured is likely because i have my environment set to crazy colours so that i can tell when i'm in one vs the other. I will double-check all, but i've had this issue for years with previous versions and have just put up with it.
If i log down into SYSPROG, the same behaviour and we don't do anything in sysprog.

KevinFournier

Version of OI? Version of Windows? If I can't recreate this, the only other option is to get copy of the offending system.

MARTINDRENOVAC

here you go:
login into sysprog

Removed by system administrator

DonBakke

Martin,

I've downloaded your system and have installed it on my local machine. I am able to recreate this behavior, albeit it is slightly different than how you described it. In my case, F1 works perfectly well. It is Shift+F1 that causes the problem (which is the accelerator key assigned to Help > SRP Help). Please confirm if this is what you meant.

I would like to go back to the custom coloring of your system. How exactly are you setting these colors up? From what I can tell, you are manually editing the SYSREPOSWINEXES record. Is this correct? I'm not sure it is relevant, since I did reinstall the SRP Editor in your environment and the behavior still persists. Nevertheless, this worries me as it suggests the possibility that you have tinkered with other parts of the core OI system and this could be directly related to the problem. Please clear this up for me as I do not want to have us chasing our tail if the problem is external rather than internal.

MARTINDRENOVAC

Don, colouring is made via:

Database Manager, Window Forms settings
I am not editing anything manually, am not that clever.
I have other OI systems that work perfectly with F1, this one fails
F1 is giving me grief.

If it's something you guys can see quickly, would be great to be fixed, otherwise don't worry.
My main system is working fine - on the same laptop, just a different directory.

BarryStevens

Don,

F1 is not working in his other sections of the OI system.
So the MENU.HELP must be corrupted somewhere.

DonBakke

Barry had keen eyes on this. It led me to discover the real problem.

It's not a corrupted MENU event handler. Ultimately it's because virtually all of the .CHM files are missing. This is why none of the F1 help menus work in the OI tools. Heck, even the Help button on the Application Manager doesn't work. Martin's system has F1 in the SRP Editor tied to the local CHM help file whereas Shift+F1 is tied to the SRP Wiki help. This is why F1 behaves unexpectedly but Shift+F1 works just fine.

To force the CHM help file to actively search for the highlighted word, we send a carriage return to the active window, which we assume will be the CHM help file since that's what we just launched. In Martin's case, the CHM help never launched, so the carriage return gets directed to the open SRP Editor document. Voila...bad behavior.

Our next release has a safety check for ProgRef.chm. If it is missing, then nothing happens.

MARTINDRENOVAC

BARRY for president!

MARTINDRENOVAC

one more little fix to the editor, not a biggie though
if i do a global change of Return to RETURN - all works except when the last physical line is Return
if the last line is blank, it works.