hello, I have a question, I'm cre

[icecr3amc4k3]

hello, I have a question, I'm creating a multi-login program, currently the main form is form 1.. but when I move to this form, the main form appears and it obstruct

how to fix it?

Thanks Everyone

 

[Mike Lewis]

It's difficult to understand your problem. Your screen shots don't give much information, and it's not clear what you mean when you say "currently the main form is form 1.. but when I move to this form, the main form appears and it obstruct".

Looking at the upper screen shot, it looks like you are running a form (this is presumably your login form), but you are also seeing certain elements of the development environment, including the main menu, a toolbar and a property window. If you want to hide those items, you can do something like this:

* hide the system menu
SET SYSMENU OFF

* hide the main toolbar 
IF WEXIST("Standard")
  HIDE WINDOW "Standard"
ENDIF 

* hide various other windows
DEACTIVATE WINDOW "Document View"
DEACTIVATE WINDOW "Properties"
DEACTIVATE WINDOW "Command"
DEACTIVATE WINDOW "View"

I don't understand the lower screen shot. It looks like you are in the form designer, with a code editing window open, and with a label and perhaps an image visible in the form. I don't see what the problem is there.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Aside from Mikes method to remove all the IDE related windows, if you build an EXE from your project and run it, this also is gone. By the way, then the problem of the current directory also becomes unimportant, because you can DO any form that's built into the EXE without VFP searching scx files, it finds all forms that are in the EXE.

During developement, you simply close the windows you don't need and have the system menu to interact with the program for example suspending it and starting the debugger.

Chriss

 

[Mike Lewis]

As Chris says, this is not an issue when running form an EXE, as the various windows will not be present. But an exception is the system menu. That will be present when running from an EXE, although most of the items will be greyed out. So you have to explicitly hide the menu (using SET SYSMENU OFF). On the the hand, you don't want to do that when running in the development environment, as you might need to use the menu to suspend, cancel or resume the program or start the debugger.

One solution would be like this:

llRunTime = (VERSION(2)=0)
* llRunTime is a logical variable which will be
* set to .T. when runing from an EXE.

* You could then do this:
IF llRunTime
  SET SYSMENU OFF
ENDIF

You can use a similar technique to decide whether to activate an error-handler, as that is something you should have in an EXE but probably not in the development environment.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Maybe your confusion arises from the fact that the VFP IDE works different from many others I know in not needing to first compile sourcecode to an EXE and run it. If you run a form it runs in the IDE window, the IDE still also is active and while you run a form you could modify another form in parallel and have it open in the form designer. Your second screenshot shows a form designer windows, where clicking on a button does not run the button but opens a code editing window showing the source code of the click event. You're not running the form, your modifying, editing, programming it.



Chriss

 

[ggreen61]

merpati89--

You have much to learn about VFP. First you need to learn about modal vs. non-modal forms. Then you need to learn about top-level forms. Also, you need to learn about the READ EVENTS command. A form run inside the VFP IDE will display; however, if you compile it to an EXE and try to run it outside of the IDE, it will flash on screen and disappear with the EXE ending. So, look for some training materials on building VFP programs.

Greg

 

[Mike Lewis]

Greg is right, of course. And given that there is such a huge amount of VFP-related material available on various websites, there's really no excuse for not taking the trouble to learn it.

A good place to start would be the FAQs here on Tek Tips. In particular, Greg mentioned the issue of forms that "flash on screen and disappear with the EXE ending". This is one of the commonest issues that newcomers experience. The solution is described in faq184-4232.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Hello merpati,

from your profile here on Tek-Tips I see you last loged in on May, 24th, as of now. So, I see you're still reading responses to your threads.

I know, it's not nice to see people talking about you while you're in the room, so let me address you directly, once more. You're welcome to ask your questions and continue, just make it more operable and also give feedback, please. A forum is always also a knowledgebase of others finding help by just searching the forum and it helps them not only to find their question (by better question titles) and the answer - what the experts say, but also confirmation what worked. And that works best with a feedback of what code you finally used, for example.

As I come back here, I also see now, how you make beginner mistakes in login coding. You store the passwords in your data as plaintext. That's a big security issue. By default users runnning the software and its login do have access to the data of it, otherwise your code couldn't access the DBFs. So even if they only access the data through your software, they have access to the full DBF files (and related) and can look into them with readily available DBF viewer tools, etc.

The industry standard for password storage is to store so called password hashes. I won't get into more details about that. This is surely not a beginner topic at all, as it involves knowing quite a lot about cryptography. If you stick to that just for the purpose of learning all about VFP forms and controls and data access/binding and some flow of login logic like limiting the number of failing logins, then this is fine and you can upgrade this to include security later on. You just might want to come up with another overall starting project as the motivation to learn with a real world example of an application feature.

I get the idea, you don't want to learn just for learning, you want the result of the learning to be something usable, too. It just always introduces the problem that at some point you'd have to learn something that's off the track for beginners. It's always possible to deep dive into such specialties, but then you can't really make it a course within a course to sufficiently learn what you need to know and half knowledge about something like cryptography is bad.

Chriss