At work, attached files size to email is limited to 10 Mo and because of many reasons :
Outlook is the only way to share files
I can only use the programs already installed
I am trying to create a VBA macro to :
automatically split PDF bigger than 10 Mo by printing them into smaller files
merge them on the other side
I know it is far from ideal (and many tools exists to do it), but I have no other options.
So far, it seems that I can only use PDFCreator and Adobe Reader for this task, as no other helpfull tools are deployed on my PC (mostly Office)... and I can not figure a way to use command line for printing range of pages.
I successfully created a working (very) inelegant macro, based on Shell commands and SendKeys VBA, basically emulating human interaction to print range A, then waiting for the job to be done, them printing range B, and so on... Among the many problems I should now solve :
add protection to take into account machines with different processing power (replace my timings with file creation verification and detect if jobs are still running in the background)
create a robust merging system when receiving the mail
Plus I am very dependant of the software versions installed, and I foresee a lot of issues with software updates/version if this macro is to be used by many people.
So this method doesn't have a bright futur for now, and unless I find an other way to solve this problem, I will probably give up and keep doing this manually (after all, if my employer doesn't provide better tool, I should not be expected to be as efficient as I could).
Have you any insight about how to cleverly solve this issue ?
(Yes, I already told my boss that working like this is a nightmare, but easy file exchange is not the priority).
I managed to solve my problem using 7-zip and its "-v" option using command line : I split my big file into binary smaller files and automatically create new mail with them as attachments.
Related
I am still learning zpl. I have created some simple labels using the Zebra designer and converted them to zpl files and added to printers. Now, I have been tasked to update existing labels for some of our customers and I do not have the file available in the designer. I have been successfully been able to do things like update a barcode type and add a field by directly updating the script. But, the changes the users want would be much easier if I could use designer (I know that is like cheating!). But, the timeline I have is short. I have found some older questions out there that say this is not possible, so I thought I would check to see if it may now be possible to use the script on the zebra printer, and convert it to text that the designer will recognize.
I would like to mention that the printers I work with are physically located in other countries, with most inside restricted manufacturing production areas. When testing, I have to coordinate with users who have access to these printers. This means that printing one label, and then receiving a picture of this label can take several hours. I am still waiting for results of one test we did yesterday! Thanks to this site, I have found a site on line that will kind of mimic the label, but the actual printed copy is the best test.
Thanks for your attention.
You cannot import the ZPL back into a designer, but there are two tools that are very helpful when you don't have a printer to test with:
Labelary Online ZPL Viewer
Chrome ZPL Plugin
I've used both and have been pleased with the results, but your experience may vary depending on the complexity of the label.
I need to drive a testbench with labview.
The test scenarios are written in a languages that can be automaticaly translated into labview diagrams.
Is this an API that allow to create "labview diagrams" from another software ? or with labview itself ?
I agree that LabVIEW scripting is one approach, but let me throw out another option.
If you are planning to do a one time migration from your test code to LabVIEW than scripting is great, but if you plan to regularly update your test code (because it's easier to use the "test" language than LabVIEW) than it could become quite painful to constantly perform the migration every time your test code has changed.
I've had great success with simply putting my state machine inside of a for loop and then reading in "commands" from a text file that was generated using my "test" language (see pic).
For example, to do an IV sweep my text file might say something like:
SourceV, 5
ReadI
Wait, 1
SourceV, 6
ReadI
This image is greatly simplified - I'm not using a state machine and I don't show how to use "parameters," but I can provide a more comprehensive example if needed. Again, I've had great success doing this with around 30 "commands" controlling multiple instruments and then I generated the text input using VBA or Python.
It's called LabVIEW scripting. You will need to enable an option in the VI Server page in the options dialog to see the relevant features.
A few things to note:
Scripting isn't complicated, but you do need to be aware of how LV code is built.
While scripting is public, it was initially created as an internal tool. There are still corners of it which are incomplete.
Scripting code can be tedious. If you can get away with it, try creating templates of code.
NI has something called CodeGen, which I believe are a series of functions which make some scripting easier, although I never really looked into it.
I teach at a university and one assignment i have developed tests some quite specific modelling skill sets in Excel. Because of this, and because all assignments need to be fairly weighted, they end up having largely the same content (in terms of the final code) with different variables so that they are not exact copies - so it is fairly easy for students to take another persons completed file and input their own variables, change a few cosmetic items (drag data locations, colours, borders etc) and hand the work in as their own. i am confident that this is occurring and most of the time i can identify the suspects easily but proving the collusion (not so much detecting it), this is difficult.
I am trying to work out how i can include somewhere on the worksheet (which i will provide as a template) a function that logs the user ID and time each incidence that the save button is pressed (or at a set interval)? This way i can have this info logged in the background (hopefully where nobody can find or goes looking for it) and it will be quite easy for me to see if at any point along the way the student working on the sheet changed - indicating collusion. Of course there are other ways around this, and i am not looking for a fail safe system, just an easy way to catch lazy cheats.
I can find functions that save the last user to a cell, but none that can provide an ongoing log. Ideally, i would like it to be as covert as possible, i.e., avoiding obvious macros would be handy but i can understand this might be a problem. Does anyone have any tricks up their sleeve to help me in my quest to wipe out student copying?
Type sign in Excel's help. Look at digital signatures. There may be some way of using them?
From Help
After you have installed your digital certificate, you can sign files and macro projects.
When you digitally sign a file, you certify that the information in the file is valid and that it has not been modified since the file was signed. As long as a file is unchanged, reviewers can attach signatures to it. You might use a digital signature with important files. When you digitally sign a macro project, your digital signature says that you guarantee that the project is safe. Just as signed files remain signed until the file is modified, signed macro projects remain signed until the macro code is altered.
Or perhaps turn on track changes and make an initial change yourself.
reputedly, it is possible to make a "malicious" Word document. Maybe using embedded VB script? Anyway, not sure. My question is, is it possible to make an app that safely scrubs all such insertions from a .doc file? Of course, preferably this app should work without actually opening that file in Word application since presumably that may be sufficient for the machine to get damaged.
Is there something like that out there already? Is this even a problem worthy of discussion or in reality there is nothing really malicious that can be done using the Word documents distributed online?
ADDED LATER: johnnyArt, yes, and when you get dirt on your clothes, make sure to go to mommy and tell her about it. Mommy knows best! As a computer programmer, I am interested in learning more about how the world works, including how the world of .doc files and their embedded malicious scripts works. As for using the antivirus and anti-spyware, I will handle these issues without your precious advice. As will, probably, most other users of this forum.
You should scan the file with your antivirus/spyware of choice.
My advice is, if it has malware in it, it's not worth "cleaning" it for use.
Get yourself a clean copy somewhere else.
I'm new to VB6 but i'm currently in charge of maintaining a horror of editor like tool with plenty of forms, classes, modules and 3rd party tools all chunk together like the skin faces on that guy in the texas chainsaw massacre...
What i don't understand is why i get different results when i run the app in debugging mode, vs when i compiled it and run it on my devevelopment pc vs when i installed it on a different pc.
Yes i know i'm dumb, so please direct me to where i can find out more about this. I'm hoping to find out something like different linking, registry related etc connection that i'm simply not getting right now, i.e. something like wax on, wax off :P
The main pain in the neck is when i'm trying to debug some errors from my QA and i need to find a spare pc to test this on plus i can't directly debug because i don't know where the code is if i do it that manner.
Thanks.
i run the app in debugging mode vs when i compiled it and run it on my
devevelopment pc
When you compile you have the option of compiling to native code or pcode. The debugger runs using pcode only. Under rare circumstances when you compile to native code there will be a change in behavior. This particular is really rare. I used VB6 since it's release and I may get it once or twice a year. My application is a complex CAD/CAM creating shapes and running metal cutting machine and has two dozen DLLs. Not a typical situation. At home with my hobby software I never ran into this problem.
There are another class of errors that result from event sequencing problems. While VB6 isn't truly multi-tasking it has the ability to jump out of the current code block to process a event. If it re-enters the same block for the new event interesting things (to say the least) can result. I think this is the likely source of your problems as you software is an editor which is a highly interactive type of software.
In general the problem is fixed by reordering the effected areas. You find the effected area by inserting MsgBox or write to a text file to log where you are. I recommend logging to a text file as MsgBox tend to alter behavior that are timing or multi-tasking related.
Remember if a event fire while VB6 in the middle of a code block and there a DoEvents floating around then it will leave the code block process the event and return to the original code block. If it re-enters the same code block and you didn't mean for this to happen then you will have problems. And you will have different problems on different computers as the timing will be different for each.
The easiest way to deal with this type of issues is create some flag variables. In multi-tasking parlance they are known as semaphores or mutexes. WHen you enter a critical section of code, you set it true. When you leave the routine you set it to false. If it is already true when you enter that section of code you don't execute it.
when i installed it on a different pc.
These are usually the result of the wrong DLL installed. Most likely you have an older version while the target has a newer version. I would download the free Virtual PC and create a clean Window XP install to double check this.
If your problem is event timing this too can be different on different computers. This is found by logging (not MsgBox) suspect regions.
If you can display a screen shot or the text of your specific errors then I can help better.
The first thing to check would be the versions of all the dlls that your app depends on - including the service pack version of the VB6 dll.
Have you any more specific details about what's behaving differently?