DEFINE WINDOW questions

[dkean4]

I have a form which allows me to edit VFP code in a window (positioned in the same form) with the full VFP IDE as one would normally do in the VFP IDE using "MODIFY COMMAND ABC.prg" in the COMMAND WINDOW.

I am able to do this just fine with the following code, but there are problems.

SELECT resonator

ThisForm.editing_on = RECNO("resonator")

SET SAFETY OFF 
STRTOFILE(resonator.codeSnippet,"EDITING\Snippet.prg")
SET SAFETY ON  

DEFINE WINDOW xCode ;
	FROM 12,52 TO 61,130 ; 
	TITLE "EDIT CODE" ;
	FONT "Courier New",10 ; 
	NAME CEditor ;
	SYSTEM FLOAT CLOSE GROW ZOOM
MODIFY COMMAND "EDITING\reactions.prg" NOWAIT WINDOW xCode IN WINDOW FORM1

One problem is that I have to do several steps to save the file back into its MEMO field. As you may see above, the code resides in a MEMO field, which I push to a file, in some directory. Ideally, I would like to click outside of the editing window on a SAVE button, which could replace my current "Ctrl+W" to save the file back in the OS directory... and then move the file from the directory back to the Memo field (with a Single click).

I am in this problem because I keep the code in a memo field. The code "MODIFY MEMO codeSnippet" does not fire up the VFP IDE. So, typing "strtr(" does not translate to "STRTRAN(" etc... in the Edit Window which is set up with the definition above

Here is the idea... with the Save button which would save the contents back to the MEMO field

Any ideas would be appreciated.


Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Mike Lewis]

Not sure what your problem is. Are you asking what code you should write in your Save button? If so, I would think you only need to [tt]KEYBOARD {CTRL+W}[/tt] to save the file, then do[tt] FILETOSTR()[/tt] to get it back into the memo field? Or am I missing something?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Or, is your problem that the Ctrl+W doesn't work, because when you click the Save button, the text editing area no longer has focus? If that's the case, then the solution would be to place the button on a toolbar rather than in the form. Since toolbar buttons never get focus, that should solve it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Take a look at

http://doughennig.com/papers/Pub/200511dhen.pdf

Quote:

ike design time, there are two places IntelliSense is supported at runtime: in a code (PRG) window and in a memo field.
It’d be really nice if it was supported in an editbox because of the control we have over that object, but no such luck.
Note that getting IntelliSense to work with a memo field is a little tricky: you need to ensure that word wrap is turned
off and syntax coloring is turned on, which means providing a custom FOXUSER resource file with these settings in place.

You should read more about the necessary foxuser.dbf records to get intellisense active in a MODIFY MEMO, but it is possible. Also look into _VFP.EditorOptions.

Bye, Olaf.

 

[dkean4]

Mike,

CTRL+W works fine, but once you save the file with CTRL+W, from the code window, the file contents have to be uploaded back into the MEMO field. That makes it two steps. I need a one step action like clicking on a button and everything needed takes place...

Unfortunately DEFINE WINDOW with the MODIFY COMMAND commands create 2 windows, both of which are a serious pain in handling within a modal form. I learned to not activate the xCode and let the MODIFY COMMAND window come up on its own.

The strange thing is that both windows sit in the form, but are virtually inaccessible from the form. There is no way to access it with something like "ThisForm.xCode". Also, clicking outside of the MODIFY COMMAND window does not readily let you get back in, because a modal form elbows everything else out of the way and the editing window, though in the form, is not really within the private realm of the modality. So it is treated as an illegal alien.

I'm not sure what they were thinking by creating this enigma. I finally had to part with the Modal feature of my form @$%&@#!



Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Mike Lewis]

CTRL+W works fine, but once you save the file with CTRL+W, from the code window, the file contents have to be uploaded back into the MEMO field. That makes it two steps. I need a one step action like clicking on a button and everything needed takes place...

But, Dennis, it is only one step: a single click of the Save button. It is the code in the click event of that button that keyboards the CTRL+W and writes the file back to the memo. As far as the user (presumably yourself) is concerned, there is only one action.

Unfortunately DEFINE WINDOW with the MODIFY COMMAND commands create 2 windows, both of which are a serious pain in handling within a modal form. I learned to not activate the xCode and let the MODIFY COMMAND window come up on its own.

The article by Doug Hennig that Olaf mentioned deals with that specific point (about page 4). Doug does not use the IN WINDOW clause, and he explains why in the article. I ran Doug's code myself, and it seems to work as expected (but not with a modal form, as far as I can see; is there a special reason why your form has to be modal?).

I'm not sure what they were thinking by creating this enigma.

Well, to be fair, MODIFY COMMAND was always intended to be used directly in the development environment, not to provide a code-editing window from within an application. I'm not saying that you are wrong to try to use it in that way, but I wouldn't be too surprised that it doesn't work completely smoothly.

Mike





__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dkean4]

Mike,

For the window to receive the CTRL+W you cannot be outside of it. When you click the SAVE button your focus shifts to the button and the ensuing CTRL+W is irrelevant!

I read the article as well. Fortunately I found a solution. I killed the Modal feature and used the MOUSE CLICK command to pass the focus to the xCode window and apply the CTR+W by proxy. This way I do not have to add any lengthy code to achieve my goal. It is fairly simple. I was hoping to get some info on how to get a handle of the created xCode window within the form and massage it at my pleasure. I guess that is not possible.

And yes you are correct about the idea of the MODIFY COMMAND, but I like to complain even when it is not appropriate. MS is my favorite socker ball. B-)

Time for me to reform.



Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Olaf Doschke]

You read the article and still are with MODFIY COMMAND? You can MODIFY MEMO. Well, what remains is a popup window, you can't have intellisense in an editbox, as Doug says (" but no such luck"). But it removes the need to save memo to file and bring it back...

Bye, Olaf.

 

[Mike Lewis]

For the window to receive the CTRL+W you cannot be outside of it. When you click the SAVE button your focus shifts to the button and the ensuing CTRL+W is irrelevant!

That is precisely why I suggested putting the Save button on a toolbar. Toolbar buttons don't receive focus, and so your edit window will still have focus at the time of the CTRL+W.

But never mind. You have found another solution, which is good.

I like to complain even when it is not appropriate. MS is my favorite socker ball.

Well, I guess you are not the first programmer in the world to be of that opinion, nor the last.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dkean4]

Olaf,

As usual you hit the spot. Excellent article. But I decided against using that method, probably because all I needed was one more line of code to get my stuff working... "MOUSE CLICK AT 30,100".

Now that it is working and I can use it, I will review it again. I'll let you know how it worked out...

Thank you very much, Olaf,

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[dkean4]

Mike,

Sorry, I forgot to mention that I do not have a menu on this form. So your idea is excellent. You steered me in the right direction.

Thank you for your kind help. It is very appreciated.



Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Olaf Doschke]

Notice the PIXELS clause of the MOUSE command. It might be more appropriate and also easier to determine a valid mouse position to click at programmatically in pixels.

Bye, Olaf.

 

[dkean4]

Olaf,

As usual, you are right. I was looking for it and did not see it. You are a real Guru, Olaf...

Thanks...

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Mike Lewis]

MOUSE CLICK AT 30,100

I'd be a bit worried about hard-coding the button co-ordinates like that. It might be better to use OBJTOCLIENT() to get the co-ordinates - with a possible conversion between foxels and pixels (not sure about that).

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dkean4]

Mike,

Wow, I have been looking for that command for so long. I did not even know that it existed.... ha ha ha...

"Relative to the form"... Awesome! Years ago, I created a function to reverse loop through the parents and containers backward until I hit the form. Time to chop out the excess...

I swear... I love VFP every day some more...

Thanks, Mike.

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Olaf Doschke]

...reverse loop through the parents and containers backward until I hit the form

OBJTOCLIENT can only help with an object reference and with control embedded on a form, you need something else for finding relative form positions. I get weird results with OBJTOCLIENT passing in a form object. negative values for left, for example, while the form is surely within the visible _screen region. I would have expected the form position relative to _SCREEN, but it's in relation to the desktop and I see now, why this is negative. I have a setup of three displays with main display in the middle, so coordinates of the left display are negative.

So OBJTOCLIENT returns positioning of forms relative to the desktop, also for In-Sreen forms.

That means in the end OBJTOCLIENT(form2,1)-OBJTOCLIENT(form1,1) gives top position of form 2 relative to form1 and so on. Should be usable for the MOUSE CLICK.

Bye, Olaf.

 

[dkean4]

Olaf,

Thanks for sharing. Good to know...

I have 3 screens to the left of a 4K TV monitor and I run into these problems galore. My main monitor is the 4K. Some applications like PhotoImpact have tools which on the left screens will set to max values and I have to move the application into the 4K display to use them. Multi-Monitors are a bitch. In VFP, the Grid Mouse scroll works when it feels like it on my left side monitors. Effectively it is useless. So, I got it...


Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci