am i doing this right? 3

[dexterdg]

i was making an information system and upon completion:

Q1: in the log in my app. how do i manage this? will i let the users(admin is the level of the users) to delete log and look like cheating? or will i let it list thousands of transactions on the app that i imagine is sort of messy. in this log, *considering* i made a print and export log table(xls) for copy/back up [hard copy & soft copy]

Q2: how do i publish this like export or lay mans "FINISHED PRODUCT"?
i created a prg and imported all my forms, menus, and tables there and Build->Win32 executeable/COM Server(exe)->OK "is it right? what i just did?"

Q3: is this configuration on building is network ready? i mean if i put this in the server, its networks will be able to use it just like that? its kinda my first time to do this so i need everyone's aid

thanks in advance
Dexter

 

[JRB-Bldr]

Have you looked over the free on-line VFP tutorial videos at:

http://www.garfieldhudson.com/FreeVideos.aspx

Paying special attention to:
* Building a Simple Application - Pt. 1
* Building a Simple Application - Pt. 2
* Building a Simple Application - Pt. 3
* Building a Simple Application - Pt. 4
* Building a Simple Application - Pt. 5
* Building a Simple Application - Pt. 6

They might give you many of the answers and re-assurance you need.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

Q1: If yo want an answer on that, I need to know more about the nature of the log. There are a gazillion trilion things you may put into some log, and whether you make that visible and deletable is very application specific, isn't it? I get the feeling you seem to think there is some log any programming language writes. VFP doesn't log anything on it's own. Tell more about what you mean.

Q2: What you build, is up to you. An EXE is an executable, it's what a windows application is, any other type you see there (APP or two types of DLLs) is not self executable, is it? As you have no other choice, it must be the right one. If you want to know more about what each is, the help will tell you. The build dialog has a HELP button, leading you to the help topic. In general F! is giving you contextual help, when you move around in the VFP IDE. The help topic you see also leads to more detailed help. And you have to have a general Windows knowledge about what an EXE and DLL is. APP is VFP specific and is not executable in itself, just when you have VFP itself installed you may also start an APP. It's a prebuild for any EXE without the part of the code making it an executable. Still you always need to also deploy runtimes, I think you know that already, if you recently read what others asked (a recommended thing to get a feeling about VFP and not too much asked) you could know that from sdockers thread about his installshield problems.

Q3: If your app is network ready depends on your programming. An EXE is an EXE, it runs on Windows, netwoked or no doesn't matter. What files it opens and if they are local or on the network merely depends on your programming. If you want to know the general possibilities, and you need a network ready EXE, then if I were you would ask that before starting programming, otherwise you risk wasting your time. But to remove your fear: Foxpro is capable to read from network shares, even if not mapped, you can use UNC pathing, that means you can adress a network share with the syntax \\servername\sharename or \\servername\d$\, if drive D is shared. VFP is respecting all the access control security settings of the file system, you don't need any special library for addressing the network.

Bye, Olaf.

 

[JRB-Bldr]

In short - what Olaf says is "IT DEPENDS..." and he is correct!

Because there are so many user-specific, application-specific network-specific and developer-specific variables involved to provide any finite answers to your questions, that is why I pointed you to the tutorials where you can see how (IN GENERAL) things are done and then decide if what you NEED to do fits the model shown.

Good Luck,
JRB-Bldr

 

[IlyaRabyy]

A.to Q#1.
Well, not exactly The Answer, rather some idea I've been implementing for a long while.
Imagine you made an app that is to be sold "off-the-shelves" to external customers; needless to say, you also have internal users of your app (testers in QA dept., or users in your company's remote offices). I'm sure you know how it goes when some well-hidden bug rears its ugly muzzle ( ) at the customer's: they call you and tell you: "Your bloody program ain't workin'!" - without giving you any info on the error's characteristics... Nuf said!

Therefore, I have an error handler in all my programs (in my class of 100% generic objects); when I need to override it in a specific sub - I use TRY-CATCH-ENDTRY construct. Either way, I need to get the info on the error written in a file, which I can either access (internal users) or receive from the external users by other means (think E-Mail). Therefore, I have my error handlers and/or CATCH sections write the error info into an error log file (ASCII or DBF - does not matter). That same handler also "keeps and eye" on the size of that error log file, the size limit being set either by default (say, 32 KB) or by the developer, coz I've MaxErrLogSize property in my generic objects... The rest is just "technicalities" anyone here can figure out him/her-self.

Just the idea, but HTH.

Regards,

Ilya

 

[dexterdg]

Q1: was about the logs of the actions the user has done, e.g. "use1 has added a profile" just lists like that.
Q2: like mr.olaf said. it might be the right one. is it normal that when i run it theres two(2) added db? what's that for?
Q3: how can i say my coding is network ready? i mean im just using texts no images or other extensions. should i still be using UNC pathing on my tables?

thanks
Dexter
my project is near to its completion
thanks guys so much helped a lot!

 

[Olaf Doschke]

Q1: Well, if you log your own messages it's up to you who should be able to see log entries, and delete them. It depends on laws of countries, if such user specific data logging is violating data protection laws, personal rights on own data etc.

Q2: EXE is the right one, no fear. an app or dll may accompany an EXE a additional component, but an EXE is the first thing you need, you can't run an APP, you can RunDLL a DLL, but not a DLL you create with VFP. You can only create DLLs including COM Server classes and can then instantiate them via CREATEOBJECT(), but if you want an entry in the start menu, an application starting via double click on it, that's EXE. Look at any application on your computer, any start menu entry starting an application, what do the entries point to? EXE. We're on windows here. EXE stands for Executable.

Nevertheless, as I initially said what you build is up to you. You can make it more complicated for yourself and compile to a DLL and then develop soemthing in another language using the COM classes of that DLL, you can build an APP and then start that from another EXE, or ask your customers to buy a full VFP9 license to be able to execute your APP.

I feel like talking to a wall. This is not about VFP knowlegde, this is windows knowlegde about what a DLL or an EXE is. The only question you could have is, if an APP is sufficient to deploy on a client target computer. It's not, if you don't have an EXE with DO your.App or Do some.prg IN your.app. But it can be good to extend a central EXE with several APP modules.

Why don't you try out yourself? The same project compiles as EXE, APP or one of the two DLL types. You'll see what happens, when you try to execute these.

Q3: Well, what did I say? If your app is network ready depends on your programming. Perhaps a bit more to the point: It depends on the location of your data. If your data will be installed on some network share you will need to open tables from the network, but it's merely a change of paths. VFP can access data from network shares the same way as on local disks, it's merely a change of paths.

You will have an INI file or any other means of config file to store a path to the DBF directory or to a DBC there to enable users putting data somwhere central. It's up to you, up to your programming, incuding how you program your setup to put EXE and data seperate.

How doe application using a central database install in general, independant on the programming language? There has to be a database install for a server and an application install for each client. You may combine both installs into one and let it only install the database, if it isn't at a specified directory. If you don't know how to create a setup putting everything in place, then perhaps ask in a forum of your installer product.

Bye, Olaf.

 

[Olaf Doschke]

Q2: how do i publish this like export or lay mans "FINISHED PRODUCT"?

To go about this question from scratch, let's take the term "FINISHED PRODUCT" as what is installed at the target computer, target customer LAN or even in the internet.

What you need to get there is an installer. And there are many installer products available, which all enable you to put together your EXE, any seperate FRX you want seperate, any images you want seperate, any OCX or other third party tools, all DLLs by third party or yourself, any APP of yourself or third party or natively belonging to VVFP like the REPORTOUTPUT.APP, the foxpro runtimes, eg vfp9r.dll, gdiplus.dll, the C++ runtime, as VFP and the VFP runtime are programmed in C++, msvcrt.dll in some version specific to your vfp version etc., or Merge Modules, if the installer supports these.

You need to know what you used and some help chapters of VFP do tell about the deployment / distribution process to get to your setup.

In the process of creating an installer you setup into which system folders all your files, EXE, DLLs, APPs, DBF, FRXes, LBXes, OCXes etc. go, and/or you have sections of your installer asking the user to browse for a destination directory.

And how you do this is question partly for this forum, what vfp specific files you need, and partly for the forums of the installer product you use, how do you sepcify destination directories, target OSes allowed, target access rights, registrations of DLLs or OCXes, etc, etc. And you have to ask a much more specific question to get more specific answers. What you need depends very much on what you did develop. You need more than VFP knowledge to decide what you need, you need to know a bit about windows, system folders, ActiveX registration, ODBC administration, whatever is involved. There is no one size fits all solution and answer. This is very individual and depends on what you want to do.

Bye, Olaf.

 

[dexterdg]

oh wait! am i going to database my free tables here? to be able to cope with networking this app?

 

[Olaf Doschke]

> an INI file or any other means of config file to store a path to the DBF directory or to a DBC
This means: no. You don't need to database your free tables.

But your application surely needs to know where data is installed.

You don't need such an ini file, if you install data directly into the applicatio directory, but obviously then only the local computer and local users will be able to see the data. Isn't it that way?

It's mere logic you need to put your data somewhere centrally available to all users.

Bye, Olaf.

 

[dexterdg]

this app is going to be installed in the server and can be accessed by clients[full access] in a network[LAN].
so basically if my app is not that complicated[doesn't requires UNC pathing because the only information i manipulate are text data] i just have to install it in the server so its centrally available to all users?
just like that sir?
the "But your application surely needs to know where data is installed." part. i think i didnt understand this part. if the app is run on the client, do i have to specify that "hey data is on the server" or it does it for itself?

thanks
Dexter

 

[Olaf Doschke]

Well, we're no talking of "knowing" in an intelligence or artifical intelligence way.

I don't nkow how you access your data, but anyway, you open DBFs, and if you EXE will not open them it'll error, at least then you'll see. I don't know yuor program, so I can't tell you what you need.

You're a bit more specific now about the way you intend to install. It's not a recommended way, I recommend, and I think others would also recommend, to install the data central, but the appilcation exe local for each user.

When you start an EXE the current directory will default to the directory of the EXE, so eg USE sometable will look into that directory. You also perhaps know SET PATH to specify further paths to look in for files, eg for DBFs.

When you install on a server, the essential thing to do administrative, is to allow access to all users. It's quite impossible to do that with a setup, as you would need to know user accounts in advance to set access privileges and the clients will still need to be configured to see the server side application directory. A setup you run on the server side will not be able to install lnk files to each client.

Bye, Olaf.

 

[dexterdg]

so the central will only contain the data[raw forms, dbf's, menus], run exe there so it will be its directory
and for the each user will have a shortcut of the exe/link of the exe to access the app?

also will i go to network places>pc#>[copy exe](locate for the exe from the user to the central) and make a shortcut of it to the users unit?

 

[Olaf Doschke]

>so the central will only contain the data[raw forms, dbf's, menus], run exe there so it will be its directory
>and for the each user will have a shortcut of the exe/link of the exe to access the app?

No,

1. data is DBF, nothing else. Menus and forms are inside the final EXE file, and not needed seperately.
2. The situation you describe would still be the situaation, where you install data and application at the server side and use it on the client side.

You can do this, but you will still need to at least give any user a shortcut e to the central EXE. It's not recommended, because you use the LAN for both program and data, while only the database is what changes mainly, also this kind of installing will not register any OCX on client side computers and you can't make use of such controls, then. I recommend a MSI setup run on each client side. In large networks you use a central software distribution server to do that, it's a jo of the network adminstrator. What you deliver is a setup.exe or MSI, that would install for a single client.

If your customer has no such network administrator the network will not be so large, will it?

Bye, Olaf.

 

[dexterdg]

aaa... why is that after i build the project as i run it after my log in it closes!!?? but when i run it by form its all perfect! hmm btw thanks for the help my work is d-o-n-e! my last problem is the publishing this thing. i created a project, added there the forms, menus and free tables i used then after build it closes after log in, why is that?
i used .visible and .release
tried them both but same result
i tried to put none of the above and it goes to the next form but it my menus wont work.
help fix this stuff

also, why is that when i run this exe theres a parent form on my log in? is that default? how do i remove that? im using vfp9.

thanks
Dexter

 

[Olaf Doschke]

You're seeing the _SCREEN (the parent window), and you most probably have no READ EVENTS at the end of your main.prg

To remove _SCREEN is a solution involving two parts: 1. your form must be set to top level form (or it will vanish together with _screen), and you have to hide the screen.
If your application depends on your main form being modal this will fail, as top level forms behave modeless, even if you set them modal. So you really need the READ EVENTS.

Take a look at faq184-6512

Bye, Olaf.

 

[dexterdg]

will that also solve my mdiform w/ menu that is not functioning the way its supposed to be? im really bad at this. 1st time doing this. i hate my school not teaching me this. its a headache~

 

[Olaf Doschke]

I though twe already filled your knowlegde gap about how to address forms and how to solve the menu. It's a seperate topic.

My sample code doesn't show anything about a menu, but you just need to copy over the essential bits into your project. Your form already is top level, so mainly add a READ EVENTS in your strting prg and CLEAR EVENTS in the main form unload.

If you still have problems about the menu, I suggest you start a new question. Your can reference your own older thread, by simply writing the thread184-xxxxxxxx below the caption of the thread. The forum makes that a link with the thread title, when you preview or submit. You don't have to endlessly keep open threads, because there still is a question about something, which arose in the discussion.

Bye, Olaf.

 

[Olaf Doschke]

...also add the config.fpw file generated by my code in the "other" directory. Simply copy it into your project folder, drag&drop it from there into the project manager and it will be added to the project manager in the section "other/other files". Right click on config.fpw and include it. The line, which solves the "parent" form showing is SCREEN=OFF.

Bye, Olaf.

 

[dexterdg]

i was just asking because i cant apply it now. my loptop screen is too tiny for the system i am working on and its on the office where i have access to bigger screen. its my internship